Webフレームワークでのデータベースのユーザー名とパスワードの保護
データベースを扱うほとんどのWebアプリケーションでは、DATABASESのsettings.pyのDjango変数のように、設定または構成ファイルにDBクレデンシャルを入力する必要があります。チーム内の選択された数人だけがクレデンシャルを知っていて、たとえ同じクレデンシャルでも（アプリケーションが実行されている同じマシンからでも）DBに接続できないように、クレデンシャルを保護する一般的な方法は何ですか？
サーバー認証システムと直接インターフェースするデータベースを取得します。つまり、MSSQLは、プロセスが実行するWindowsユーザーをdbアクセスユーザーとして使用できます。
本番データベースの設定をデプロイメントシステムに配置します。したがって、opsチームのみがアクセスできます。
設定を暗号化し、復号化キーを製品ボックスに配置します。
しかし、本当に安全を確保したいのなら、規律を守らなければなりません。
パスワードを知ることは許可されておらず、パスワードを見つけた場合は変更できるように報告する必要があることを開発者に伝えます。
認証ログを確認し、サービスユーザーがサービスボックスからのみログインしていることを確認します。
手動での介入が必要な場合に、適切に監査された方法でアクティブにして使用できるユーザー名/パスワードを一度だけ使用できるようにします。ルールを破って物事がうまくいくように強制しないでください。
これは一般的には不可能です。開発者が作成したコードは、ユーザーに代わってデータベースでアクションを実行できる必要があるため、開発者は間接的に完全なデータベースアクセスを必要とします。開発者と管理者は、責任を持って特権アクセスを使用することを信頼する必要があります。
非常に機密性の高いシステムの場合、実装できるセキュリティプラクティスがいくつかあります。
本番システムの管理と本番環境へのデプロイメントはtwo-manルールによって制限されます。システムにログインするには、許可された2人が一緒にログインする必要があります。ただし、これを実装するのは簡単なことではありません。
アプリケーションは、分離されたコンテキストで実行できる個別のサービスに分解されます。別の容器。機密情報は単一のサービスに制限されています。マイクロサービスは人気がありますが、システムが非常に複雑になる傾向もあります。管理者と、サービスのどのバージョンをデプロイするかを決定できるユーザーは、引き続きすべてのコンテナーに完全にアクセスできます。
単一のチームにとって、これらのアプローチはどちらも不釣り合いに高価に見えます。
資格は信頼の問題です。何らかの理由で開発者を信頼しない場合は、開発者を適切なマシンから遠ざけてください。これが良いアイデアかどうかは、この投稿のトピックではありません。
Django settings.pyファイルにプロダクション認証情報をハードコードする必要はありません。
1）可能な解決策の1つは、global_settings.pyを使用して、すべてのデフォルトを標準的に定義することです。そして、開発者はこれらの設定をグローバルにインポートしたカスタムsettings.pyを使用し、マシンの開発者認証情報でこれらのデフォルトを上書きします。 global_settings.pyはバージョン管理されていますが、settings.pyはバージョン管理されていません。人生を楽にするために、settings.py.exampleを提供して、デフォルトの設定についての正しい提案をすることができます。 global_settings.pyには、SQLite-Supportのみを含めることができます。ここで、settings.py.exampleと同様に、資格情報なしでPostgresに可能な構成を提供できます。
同じことがOPにも当てはまります。OPには、プロダクション用の独自のsettings.pyがあります。
2）もう1つの可能性は、資格情報が定義されているenvironment variablesを使用することです。
3） Hashicorps Vault のようなより複雑なシステムがあります。
どちらを選ぶかはあなた次第です。