開発者からの機密データの保護

MySQLとMongoDBの両方のデータストアを使用するエンタープライズアプリケーションを実行しています。私の開発チームはすべて、アプリケーションのリリース、メンテナンスなどを実行するために、マシンへのSSHアクセスを持っています。

ユーザーがアプリケーションに非常に機密性の高いデータを保存し始めたときに、開発者がこのデータに間接的にアクセスしているために嵐が発生したため、最近ビジネスでリスクを提起しました。アクセス可能。

私には、アプリケーションがデータベースにアクセスできる場合、マシンとアプリケーションソースにアクセスできる開発者は常にデータにアクセスできるため、これは不可能に思えます。

セキュリティは、プロジェクトの終わりに手を振ることができる魔法の杖ではありません。1日目から検討して組み込む必要があります。システム全体の一部として定期的に、これは最も弱いリンクと同じくらい強いだけです。

現状では、セキュリティの懸念事項にフラグを立てていますが、これは良い第一歩です。今、最低限、以下を定義する必要があります。

• 保護しようとしているデータは何ですか？
• そのデータを誰から保護しようとしていますか？
• 実際に誰が何にいつアクセスする必要がありますか？
• そのデータが侵害された場合の法的/財務/ビジネスへの影響は何ですか？
• データへのアクセス権を持つ個人/グループに法的/財務/ビジネス上のニーズは何ですか？
• ビジネスが以前はビジネス要件でなかった場合に、ビジネスは「セキュリティを確保し、セキュリティを維持する」戦略にどのくらいの予算を割り当てますか？
• システムはデータにどのようなアクセスを必要としますか？
• このアプリケーションとこのプロセスが依存するプロセスとシステムは何ですか？
• これらの環境を保護するために何が行われますか？
• 誰がそれを実装し、プロセス全体をレビューする責任を負いますか？

これらすべてを詳細に知るまで、実際に作業するものはありません。その情報は、適用できる（およびできない）脅威とその理由を定義します。

最善のことは、必要な経験がないことを認識し、その経験を持つ新しい人を連れて行くのが最善であるということかもしれません。予算がないという回答をよく耳にします。もしそれが本当に重要だと考えられるなら、予算が見つかります。

あなたが正しいです。ユーザーが毎回追加情報を渡すことなく、アプリケーションが企業のマシンに保存されたコンテンツにアクセスできる場合、サービスプロバイダーのプログラマー、メンテナー、システム管理者などはそのコンテンツにアクセスできます。これは基本的に避けられないことであり、不安の主な原因です（エドワードスノーデンはシステム管理者であり、単に「トップシークレット」以上の特別な権限がありました。単に付与しない方法がないためです）。

これを回避する唯一の方法は、企業のマシンに決して届かない情報をユーザーに提供することを要求することです。安全なアクセスバリアを形成するのに十分な情報を誰も覚えていない可能性があるため、これは退屈でエラーが発生しやすく、したがって、人々はすぐにどこかで資格情報を電子的に保存し始め、それが新しい攻撃の標的になります（そしておそらく維持しているターゲットよりも弱いターゲット）。しかし、「当社の従業員はユーザーのコンテンツに物理的にアクセスできない」と正直に主張したい場合は、それが唯一の方法です。

（また、そのようなビジネスモデルは政治的に受け入れられなくなっているように思われることに注意してください。企業はまさにこれを行うためにセキュリティサービスによって強制的に運用を停止されています。ビジネスにとどまるという基本的な目標よりもビジネス価値）

あなたはまったく正しいです。運用上の問題を診断するためだけに、一部の開発者は常にライブデータにアクセスする必要があります。あなたができる最善のことは、関与する人々の数を減らすことによって、潜在的な損害を制限することです。

With great power comes great ... opportunity to really, *really* foul things up. 

多くの開発者はその責任や他の人を望んでおらず、単にそれを保持する「準備」ができていないので、そうすべきではありません。

質問：開発チームがライブリリースを実行しているのはなぜですか？
リリース管理の「チーム」が必要であることをお勧めします（チームのほんの一部であるだけでなく、「Go / No-Go」のような当日の「意思決定」を行うためのビジネス表現も必要です）。これにより、開発者がLiveのあらゆるものに触れるための「必要性」の多くがなくなります。

開発者と会社の間で機密保持契約を結んでいますか？重いですが、いくつかのメリットがあるかもしれません。

問題は、開発者がシステムにアクセスできることです。デバッグのために本番データが必要な場合は、機密情報がすべて削除されたデータベースダンプを提供します。その後、開発者はそのダンプを使用できます。

新しいバージョンの展開には、開発者が関与するべきではありません-それは純粋な管理者タスク、あるいはそれ以上に-完全に自動化されたタスクです。また、リリースとデプロイは2つの非常に異なるタスクであることに注意してください。プロセスがそれを認識していない場合は、それに応じて変更します。

セキュリティのルール＃1：誰かが情報にアクセスできる場合、その情報にアクセスできます

そのトートロジーは迷惑ですが、それは本当です。個人にアクセス権を付与すると、データにアクセスできます。ユーザーにとっては、これは通常、アクセス制御を意味しますが、開発者にとっては...まあ...彼らはアクセス制御を書かなければなりません。

これがあなたにとって大きな問題である（そしてそのように聞こえる）場合、ソフトウェアにセキュリティを組み込むことを検討してください。一般的なパターンは、安全なソフトウェアをレイヤーで設計することです。最下層では、信頼できる開発チームが最も裸のアクセス制御を管理するソフトウェアを設計します。そのソフトウェアは、できるだけ多くの人々によって検証および検証されます。そのコードを設計する誰もがすべてにアクセスできるため、信頼が不可欠です。

その後、開発者はそのコア層の上に、より柔軟なアクセス制御を構築できます。このコードはまだV＆Vdである必要がありますが、本質をカバーするためにコアレイヤーに常に依存できるため、それほど厳密ではありません。

パターンは外側に広がります。

難しいのは、確かに芸術これらのシステムを設計するのは、開発者はまだあなたが期待するセキュリティであなたの会社を提供しながら、開発とデバッグを続けることができるように、それぞれの層を構築する方法です。特に、デバッグには必要以上の特権が必要であり、ロックダウンしようとすると、非常に怒っている開発者がいることに同意する必要があります。

副次的な解決策として、開発者がすべての安全メカニズムをリッピングして本格的なデバッグを行えるテスト目的で「安全な」データベースを作成することを検討してください。

最終的に、あなたとあなたの開発者の両方がセキュリティの重要な教義を理解する必要があります。すべてのセキュリティはセキュリティとユーザビリティのバランスです。会社として自分のバランスをとる必要 があります。システムは完全に安全ではなく、完全には使用できません。会社の成長や開発者への要求の変化に応じて、おそらくそのバランスは動くでしょう。あなたがこの現実に開かれているなら、あなたはそれに取り組むことができます。

別々のデータベース展開も使用するアプリケーションの2つの展開を設定します。1つは運用展開で、もう1つはテスト展開です。

テスト展開には、テストデータのみを含める必要があります。これは、その目的のために作成された空想データか、開発者がデータの背後にある実在の人物やエンティティを見つけられないように匿名化された実動データのコピーのいずれかです。

2つの金融会社では、開発者は生産マシンにアクセスできませんでした。生産マシンの変更要求はすべて、スクリプトを使用して承認プロセスを経る必要があり、マネージャーによって承認されました。dev-opsチームは実際の展開を完了しました。このチームは従業員のみであり、経歴確認に合格したと思います。また、開発者の知識もなかったため、必要に応じてスヌープできませんでした。これに加えて、環境変数に保存された秘密キーを使用してすべてのデータベースエントリを暗号化します。データベースが公に漏洩したとしても、誰も読むことができませんでした。このキーはさらにパスワードで保護（PBKDF）できるため、エグゼクティブのみがロックを解除できます。システムは、起動時にエグゼクティブパスワードを要求する可能性があります（または、dev-opsまたはdev-opsマネージャーに委任される可能性が高い）。基本的に、戦略は知識を分散させることで、必要な知識の重要な塊が一人の人間に存在せず、チェックとバランスがあるようにします。これが、コカコーラがその処方を保護する方法です。正直なところ、これらの答えのいくつかは警戒です。

MongoDBのセキュリティ制御は制限されており、安全な環境に依存しています。特定のIPおよびポート（および2.2以降のSSL）へのバインド、および粗雑な認証、それが提供するものです。MYSQLはGRANT o ON db.t TO ...を保存します。保存データは暗号化されず、デフォルトではsslは使用されません。フェンスを作成します。アプリケーション関連のログファイルへの開発者の読み取り専用アクセスは、デバッグに十分なはずです。アプリケーションのライフサイクルを自動化します。

Ansibleは、多くのシングルテナント環境での標準操作（展開、アップグレード、復元）を自動化する一方で、個別の暗号化されたボールトを使用して、ホスト、ポート、資格情報などの機密環境変数を保存しました。記録された操作のために、各ボールトが異なる役割によってのみ、要塞ホストでのみ復号化できる場合、監査可能性は許容できるセキュリティを提供します。SSHを付与する場合は、selinuxを使用してキーの改ざんを避け、管理にldap / kerberos認証を使用した要塞ホストを使用し、sudoを賢明に使用してください。