開発者にrootパスワードの近くを許可してはいけないのはなぜですか？
私はたまたま出会ったばかりです サーバールームで何かが燃えています。どうすればそれが何であるかをすばやく特定できますか？ 。コメントで私は次の引用を見つけました：
you don't let a developer anywhere near your root passwords
開発者としてだけでなく、システム管理者に非常に興味がある人として、私はこのフレーズに標準以外の何かがあるかどうか疑問に思っています。つまり、パスワードを提供しないのですか？コメント者は、これをsysadminコミュニティではかなり一般的な知識であるかのように述べています。それは...ですか？
システム管理者が完璧だと言っているのではありませんが、 開発者の例 は非常に多く、開発者であってはなりません。ミッションクリティカルなデータを持つシステムへのrootアクセスを許可されていることは言うまでもありません。
しかし、いずれにしても、それは主に行われた変更に対して責任を負うことに関するものです。多くのシステム管理者にとって、開発者はサーバー上で物事を行うように思われ、その後、彼らは自分たちが行ったことに対して責任を負いません。多くの場合、開発者は自分が取り組んでいる単一のプログラム/タスクを取得することだけに集中しており、触れているシステムの全体像や長期的な状態について考えるのに時間をかけません。彼らは安全に変更を加える方法についての習慣を学んでいません。
これらはすべての開発者に当てはまるわけではありません。システムを適切に維持できる優れた開発者は確かにいます。 95％の確率でこれらが正しいと思われることがよくあります。
のような習慣：
- 最初に開発システムでテストせずにシステムを変更しないでください
- 理解できない変更は行わないでください（盲目的にグーグルして理解できないことをする）
- バックアップシステムが機能していること、および実行したことをロールバックする方法を知っていることを確認せずに変更を加えないでください。
- システムを長期的に維持しにくくするような変更は行わないでください。 （つまり、技術的負債を追加しないでください）
- システムのセキュリティを危険にさらさないでください
- 潜在的な規制リスクを増加させるような方法でシステムを変更しないでください（PCI-DSS、HIPPA、FERPAなどを参照）。
本番システムの運用責任は通常Sysadminに関係するため、システムへの完全な管理アクセス権を持つのはSysadminのみである必要があります。これは非常に簡単です。
さて、「ええと、システムの再構成を必要とするコード変更を行うことがありますが、それに応じてシステムを再構成するためのアクセス権が必要ではないでしょうか？」
番号
コードの変更でシステムの再構成が必要な場合は、必要な要件をシステム管理者に説明できるはずです。このようにして、システム管理者は変更要件を確認し、開発者として予測できないような運用上の影響がある場合は変更を中止できます。
@NathanLongへの返答として、小規模なビジネスではこれが当てはまる場合があることを理解しています。管理者と開発者が同じユーザーであるこれらの状況では、代替策として、システムの所有権を複数の人に分割し、誰も（つまり、誰も意味しない）が自分の構成変更をプッシュしないようにします。別の開発者に変更をレビューしてもらい、3番目の開発者に再構成を実行させます。
疑いが生じたときはいつでも、変更の計画とレビューからやり直してください-他の何かが構成する恐ろしい変更管理
私は隠喩で説明しようとします（私は開発者であり、時々sysadminのことを行っています）。
画家とインテリアデコレーター
開発者が画家で、たくさんの素晴らしい絵画を作成しているとしましょう。わかりました、多分それらは素晴らしいではないかもしれませんが、彼は彼の雇用主が彼に作るように頼んだものを作りました。彼はそれが得意なので、すべての絵がうまくいきます。
次に、絵画をそれぞれの建物の中に配置する必要があります。画家はペイントについてすべてを知っていますが、壁に何かを適切に取り付ける方法としての手がかりはありません。ペインターがとにかく試すことにした場合（できるので）、インテリアデコレーター（sysadmin）が数週間後に来て、次のように応答する可能性があります。 「すべてが曲がっている、これは……これは天井に上がらなければなりませんでした！これはどのようにしてwaに接続されているのです。IS THAT GLUE !?」
言うまでもなく、インテリアデコレータはもっと良い仕事をしたかもしれません。彼はどこに何を置き、どのように取り付けるかを知っていました。彼は同じねじと時々ワイヤーを使用して一貫していた。彼は前にそれを千回やったことがあり、目を閉じていればほとんどそれを行うことができました。
長い話： sysadminは、開発者よりもリグをうまく処理する方法を知っています（少なくとも彼はそうすべきです）。彼は自分のシステムをきれいに整理し、全体がどのように機能するかを知っています。また、多くの開発者は、（たとえば自宅で）sysadminを実行することに慣れており、時間を節約できるため、可能であれば自分で実行しようとします
もちろん、1人が両方を行う状況もありますが、比較的単純な環境や、マネージャーが実際に2人を必要としていることをマネージャーが確認できなかった場所にある可能性が高いです。
向きを変えて、相手としての立場に立つことをお勧めします。
それで、その脈で：
システム管理者がソースコードを変更するためのフルアクセスを持たないのはなぜですか？
私にとって、長くて短いのは、開発者がシステム管理の観点から何をしているのかを必ずしも知っているわけではなく、それを必要としない（またはすべきではない）ため、開発者にrootアクセス権を与えるべきではないということです。 、そのため、rootを許可すると、本質的に問題を引き起こすリスクが高まりますが、メリットはありません。システムの管理は他の誰かの仕事です。
同じ理由で、sysadminsがコードを変更すべきではないのと同じです。
このアドバイスは少し時代遅れに感じられます。これは、rootパスワードを持っているいたずらな開発者が実際のシステムに侵入して変更を加える時代から来ています。
最近誰もライブシステムに変更を加えるべきではなく、開発者もsysadmin。サーバーで変更を行うのは、ChefやPuppetなどのシステムの仕事です。私たちの業界は、数年前に手動で構成できる単一サーバーの概念を超えました。今度は、多くの同一構成のサーバーを一度に展開する機能、または少なくとも任意の時点で単一のサーバーを確実に再構築する機能が必要です。これにより、rootのパスワードを持っている人がサーバーに加えた変更が、どんな帽子を被っていても除外されます。
それでは、質問に戻りましょう：開発者はrootパスワードを持っているべきですか？はい！システム管理者はrootパスワードを持っている必要がありますか？はい！どうして？なぜなら、 複雑なシステムは、エンドツーエンドで理解する賢いジェネラリストなしでは効果的に診断できない -または、少なくとも開発者とシステム管理者で構成されるチームです。また、診断の一部は、サーバーにログインして何が起こっているのかを検査する権限がないと実行できません（たとえば、開発者はstraceまたはdtraceを実行して、Webサーバーが実際に何をしているかを理解する必要がある場合があります）。覚えておいてください-見て、触らないでください！
私はシステム管理者であることに（正しく）関心がないかなりの数の開発者と協力してきました-彼らはソフトウェアを機能させたいだけです。彼らはそのために最速のルートをたどります。 chmod 777 -R .による権限エラーの修正
これは言うまでもなく、悪いことです。
私はシステム管理者コミュニティのために話すことはできませんが、経験からはできます。
彼らは彼らの物を知っているようですが、必要な細部に注意を払っていないようで、ランダムなものがインストール/変更されています。たとえば、先月、私たちのプロダクションWebサーバーの1つにKVM/QEMUがインストールされていることがわかりました！
もう1つの問題は、サーバーの役割が混在する傾向があるため、ハイパーバイザホストが突然監視サーバーとWebサーバーになることです。また、一貫性の欠如もあるように思われます。たとえば、同じ方法でセットアップする必要がある同じ役割を実行する3つのサーバーは、3つのまったく異なる方法でセットアップされます。
もちろん、コメンターは単にパスワードの代わりにSSHキーを使用すべきだと言ったかもしれません:)
通常、問題の分離のためです。一部の環境では、セキュリティを確保するために、このような制限を課す必要があります。他の方法では利用できないアプリケーションに関する情報を表示することにより、ビジネス価値を提供できます。
職務の分離と変更管理。
職務の分離とは、1人のタスクに対して1人の担当者がいないことを意味します。これを実装する最良の方法は、1人の人が1つのタスクだけを実行できないようにすることです。
変更管理については、適切に実装するために、本番システムへのすべての変更が完全に文書化されていることを確認する必要があります。これを達成するための最良の方法は、開発者にシステム管理者への配布資料を実行させ、コードとドキュメントを提供して、デプロイメントを実行させることです。
これは、IT業界で一般的な問題を単純化しすぎています。一人の人間がすべてを知るには多すぎるので、人々は自分の知識を専門化します。理想的には、タスクを実行するための専門知識を持つ人だけがそうするべきです。
現実の世界では、ITの仕組みの複雑さすべてをまだ把握しておらず、彼らが知っている会社の運用と財務の複雑さを処理している管理構造（多くの場合、 ITスタッフはしません）。
これにより、これらのITフィールドの2つが重複している場合に、OPから尋ねられたような態度になることがよくあります。そのような態度のように、ネットワーク管理者として、システム管理者も同様にネットワークを管理するように求められるので、システム管理者について同様の考えを持つことがどれほど簡単かを私は知っています。
比較的少数のケースで彼らは素晴らしい仕事をし、別の比較的少数のケースでは彼らは恐ろしい仕事をします。ほとんどの場合、彼らは2つの間のどこかでまともな仕事をすることに陥ります。しかし、記憶されているのは素晴らしい仕事ではなく、恐ろしい仕事であり、記憶されるのはまともな仕事です。
ネットワーク担当者が混在する場合（特定の理由/プロジェクトのコンサルタント、またはITスタッフが拡大し、現在は1名含まれているため）、推奨されるベストプラクティス、構成の誤り、セキュリティホールなどが無視されていることがよくあります。多くの時間は、空白のものがどのようにしてうまく機能しているかを理解しようと試み、発生してはならない問題をトラブルシューティングし、設定ミスや問題を修正しました。
しかし、これには両方の方法があり、いくつかの重複する分野が含まれます。私の例に固有のことですが、私はネットワーク担当者として、知識のあるシステム管理者ほど迅速にサーバーをセットアップできないこと、および/または見落とすか間違って実行することになる可能性があることを少なくとも知っています（または少なくとも最高の状態ではありません）仕方）。私に十分な時間を与えて、少なくともかなりまともな仕事をすることができますが、多くの場合、仕事/仕事はその時間を与えません。私に選択権がある場合、簡単に私の好みはそれを優れたシステム管理者に渡すことです。