プロジェクトのソースコードに内部サーバーでchmod -R 777を使用しない理由は？
私のアマチュアWeb開発の日々から 最小限の特権の原則 は、chmod -R 777 dirを使用しないように私に打ちのめされました。個人的には必要なかったので、使ったことはありません。
現在、私は開発チームで専門的に作業しており、最近、実行可能コードを共有内部サーバーに移動しました。会社の人だけがサーバーにアクセスでき、私たちは会社の全員を信頼しています。とにかく、コードは特にデリケートではありません。
スクリプトを実行しようとしています† 別のチームメンバーが共有フォルダに書き込んだためにアクセス許可エラーが発生したため、「それが機能するかどうかを確認するだけ」同僚が実行したchmod -R 777 /opt/path/to/shared/folderプロジェクト。それがうまくいったら、同僚は、より制御されたgroupsソリューションに切り替える代わりに、そのままにしておいても大丈夫だと言いました。
私は チンパンジー なので、私は率直に言って、これは悪い習慣だと言いたいので、groupsソリューションに変更する必要があります。しかし、考えてみたところ、内部サーバー上の共有実行可能コードに777権限が付与されてはならない理由がわかりません。
セキュリティの観点から、プロジェクトフォルダーのアクセス許可を777からgroupsでもう少し厳密なものに変更する理由はありますか？
†このスクリプトの権限要件を変更することはできません。
しかし、いくつか考えてみたところ、内部サーバー上の共有実行可能コードに777のアクセス許可が与えられてはならない理由を思いつきません。
すべてのユーザーを信頼するだけでなく、アクセス権を持つ「全員」が制御できる内部サーバーでは合理的である可能性があるため、そのサーバー上のすべてのプロセスも信頼します。 Webサーバー。 SSHサーバー。 DHCPクライアント。すべてのスケジュールされたタスクとすべてのサービス。 「nobody」および「nogroup」として実行されているプロセスでさえ。攻撃者がアクセスを獲得または拡大するために利用する可能性のあるあらゆる種類のプロセス。
なぜなら、あなたが内部開発でそのずさんなことになるとすれば、プロダクションシステムまたはカスタマーシステムではだれがずさんなことになるでしょう。
攻撃者は内部のみで重要ではない、保護されていない小さなシステムを見つけることに喜びを感じるため、書き込み可能なWebアプリケーションファイルなどの弱点を確認し、それらを使用してシステムに侵入し、それを利用してどこかに侵入します。そのシステムでユーザーが使用するパスワードは、他のより価値のある内部システムでも機能します。たぶん、あなたもサーバー間で同じルートパスワードを使用していますか？それはいつも楽しいものです。
@gowenfawrの2番目にして、ここでチンパンジーを繁殖させることが目標であると言います（今は外挿します）あなたの企業文化について乱暴に）
私のソフトウェア開発会社では、本番環境だけでなく、開発プロセスや企業のIT全般においても、セキュリティの実践の証拠を求める顧客が増加する傾向にあります。次の理由により、これは完全に妥当な要求です。
- 製品のずさんなセキュリティはデータを危険にさらします。参照： 2017年のEquifax違反 。
- 開発におけるずさんなセキュリティは、開発者がずさんな製品を書くことにつながります。しかし実際には、セキュリティが重要であるという姿勢は、開発者にセキュリティトレーニングを提供するための経営陣、適切なコードレビューを行う時間、および顧客の機能よりもセキュリティの欠陥の修正を優先する意欲が必要です。などのずさんな習慣を許可することは、企業文化がセキュリティを促進しないことの証拠です。
- ITのずさんなセキュリティ対策は、ネットワークのウイルスにつながり、コードのウイルスにつながる可能性があります。 2003年の有名なLinuxバックドアの試み を参照してください。誰かが電子的にバックアップコードリポジトリに侵入し、悪意のあるコード変更を挿入して、最終的にメインリポジトリにマージされることを期待しています。
それで、これはあなたが顧客に伝えることを誇りに思う決定ですか？
結論：最小限の特権の原則は、最も基本的な安全なコーディングの原則の1つです。それは、ソフトウェア開発プロセスの一部であるはずの考え方です。 「これが危険であることを誰かが証明できますか？」ではなく、「このようにセキュリティを弱める必要があるか？」という質問をすることです。ハッカーは常にあなたより賢いです。
もちろんchmod 777は何らかの理由で必要であり、それが最小の特権となり、ここで正当なセキュリティの議論が行われる可能性がありますが、そうではないようです。これはただの怠惰です。たとえば、データの保存方法、API呼び出しから返される追加データの量、ログに記録される情報など、最小特権の原則が製品自体で守られているという確信はありません。あなたの製品に関連しています。
プログラムが書き込み権限を必要としない限り、chmod -R 777 /opt/path/to/shared/folderが引き続き読み取りと実行の権限を許可し、目的のアクセスを実現するのに、同僚がchmod -R 775 /opt/path/to/shared/folderを使用した理由について混乱しています。
あなたのチームメンバーがサーバーにアクセスできる唯一のメンバーであることを考えると、あなたはそれらを信頼します。グローバルな書き込みアクセスがあることは必ずしも悪いことではありません。しかし、その目的は、悪意のあるプログラムや悪意のあるプログラムがファイルを変更または削除できないようにすることでもあります。ランサムウェアは、Aliceがユーザー権限で実行する例です。
- / home/alice/---（drwxrwxrwx alice alice）
- / home/bob/---（drwxrwx --- bob bob）
上記のシナリオでは、アリスが実行したランサムウェアは、書き込みアクセスが必要なすべてのファイルを暗号化して上書きします。与えられたアリスはグループbobに属しているではないであり、/home/bob/にはグローバルrwxがありません。ただし、Bobがランサムウェアをユーザー権限で実行する場合、/home/alice/はグローバルrwx権限を使用するため、Bobはrwx権限を持っています。したがって、アリスとボブの両方のホームディレクトリがランサムウェアによって暗号化されます。
ユーザーをグループに追加するのはとても簡単です Linux：ユーザーをグループに追加（プライマリ/セカンダリ/新規/既存） 。これにより、ユーザー名aliceがbobグループに追加されます。 Chown -R bob:bobuser:groupは、ディレクトリを再帰的に所有します。 chmod -R 750は再帰的にrwxr-x---権限を提供するため、Aliceは/home/bob/ディレクトリ内で読み取りおよび実行できますが、書き込みはできません。
Sudo adduser alice bobSudo chown -R bob:bob /home/bob/Sudo chmod -R 750 /home/bob/
最小限のアクセスの原則は、主に悪意のあるユーザーから保護することです。ただし、悪意のあるプログラムも非常に深刻な問題です。これが、グローバルな読み取り、書き込み、実行をまとめて------rwxが非常に悪いセキュリティ原則である理由です。このアイデアは、aliceをbobグループに追加することで実現されます。現在、ユーザーaliceはr-xに対する/home/bob/権限を持っていますが、bobグループ外の他のユーザーは、root以外の権限を持っていません。同様に、BobがAliceとファイルを共有したいが、Aliceにグループアクセスを許可したくない場合は、ABという新しいグループを作成して、AliceとBobをグループに含めることができます。これでディレクトリ/opt/AB_share/ (rwxrwx---)が作成され、上記のコマンドが適用されました。 ABグループ内のユーザーのみがアクセスできます。