アプリケーションの隣にあるデータベースをパスワードで保護すると、セキュリティが強化されますか？
パスワードで保護されたデータベースが、そのデータベースへの資格情報をプレーンテキストで保持しているアプリケーションと同じサーバー上に存在するセットアップを見てきました。
単純に保護されていないデータベースに比べて、このような設定の利点は何ですか？
データベースとアプリケーションの両方を構成する必要がある難読化のほかに、これらの資格情報に複雑さを加えるだけで、実際のセキュリティは向上しないようです。サーバーにアクセスできる攻撃者は、常にアプリケーションの構成ファイルで資格情報を見つけることができます。
編集：同じマシン内でのみ表示され、外部に公開されていないデータベースについて話している。
プレーンテキストの資格情報を保持するアプリケーションの構成ファイルへのアクセスを保護する場合、データベースをパスワードで保護することは理にかなっています。アプリケーションのアカウントへの読み取りアクセスのみを制限すると、攻撃者はパスワードを表示するためにrootアクセスを要求します。他の（特権の低い）アカウントに違反した場合、彼はデータベースにアクセスできなくなります。
これは一種の玉ねぎ保護です（別名「層状セキュリティ」 "または"Defense in Depth "たとえばSANS '"Layered Security ：なぜ機能するか」ホワイトペーパー）。攻撃者がマシンに到達できる場合、攻撃者は完全なデータベースアクセスを取得できません。アプリケーションは、必要なテーブルのみに制限されたアクセスを制限する必要があり、書き込む必要のないものはすべて読み取り専用にする必要があります。より高いアクセスには、アプリケーションで使用されていない別のパスワードが必要です。
利点は、データベースへのネットワークアクセスは持っているが、サーバーへのファイルシステムアクセスは持っていない攻撃者は、実際にデータベースにログインできないことです。
DBを保護するパスワードの利点
安全に使用できない場合は、DBとサーバーを後で分割する必要がある場合に安全でない方法で残され、将来の悪用につながるリスクを軽減します。
攻撃者が制限付きアカウントでマシンに侵入できる場合、ローカルサービスに接続できる可能性がありますが、データベースパスワードをリセットできません。攻撃者に認証を要求することで、攻撃者が実行できる損害が制限されます。
攻撃を使用してトラフィックを反映/中継できる場合、リモートの攻撃者がローカルマシン上にあるように見える可能性があります（例としては、DB APIをロードするように説得できるプロキシや、接続時に受信データを表示するサービスなどがあります。指定されたURLに失敗する）
パスワードを使用すると、異なるシステムとユーザーが互いのアカウントを使用できないようにすることができます。そうしないと、任意のシステムの攻撃者が他のシステムを装うことができます。
これにより追加のセキュリティが提供されるかどうかは、脅威のシナリオとセキュリティの目標によって異なります。セキュリティが向上する少なくとも2つの状況を知っています。
- データベースへの正当なアクセスをより細かく制御できます：メンテナンスを実行するDB管理者など、データベースへのアクセスを正当に必要とするが、内部のデータへのアクセスを必要としない人がいるかもしれません。暗号化されたデータベースは、（設定によっては）データの機密を保持しながら、DBアクセスを許可する場合があります。
同様に、データベースの一部を暗号化すると（たとえば、パスワード付きの列のみ）、アクセスが制限されます（たとえば、問題のデバッグ、レポート、またはデータウェアハウスの場合））重要な情報を保護しながら。 - データベースのバックアップを保護できます。データベースがファイルレベルでバックアップされている場合、または暗号化されたデータベースをサポートするバックアップツールを使用している場合、バックアップは暗号化されます。バックアップはデータ侵害の原因になる可能性があるため、これは便利です。バックアップは、取得元のサーバーと同様に保護されていないことが多いためです（たとえば、 を参照してください）不十分なバックアップセキュリティは、クライアントデータリークを引き起こします ）。
将来的に大きなスケーリングの懸念がない場合は、パスワードを設定するためのセキュリティが追加されない可能性がありますただし、「パスワードがない」は同じではない「アプリケーションであると主張する人を信頼する」
アプリケーションがサーバーで独自のユーザーとして実行される場合*、一部のデータベースでは、サードパーティ認証（Postgresがpeer認証と呼ぶものなど）を使用できる場合があります。これにより、サーバーはネットワークまたはオペレーティングシステムメカニズムを使用できます。どのユーザーが誰であるかを決定します。たとえば、適切な設定では、シェルユーザー「bob」はパスワードを指定せずにデータベースアカウント「bob」にアクセスできます。物事をシンプルにすることで、データベースとアプリケーションのセキュリティを簡単にすることができます。
つまり、 jrtapsell の answer ヒントとして、コストやパフォーマンス上の理由から、アプリケーションを別のサーバーに移動する必要がある場合があります。その場合は、保存されたパスワードまたは秘密鍵のような他のシークレットが必要になる可能性がありますが、これを回避するために使用できる方法は主にプライベートネットワーク内にあります。
将来的にパスワード（または他の格納されているシークレット）が必要になる可能性が十分にあると思われる場合は、今すぐ調整を行って、時間や経験の少ない人によって後で安全に行われないようにする必要があります。
*理想的には、そのアカウントには強力なパスワードを設定するか、Sudoまたは同等のメカニズムを介してログインする場合にのみ使用できるようにする必要があります
最近起こったすべてのデータ侵害を知っていますか？セキュリティで保護されていないAmazon S3バケットで、パスワードで保護されていないデータベースのバックアップを見つけたのは誰ですか？ そうです
なしデータベースが200億のファイアウォールの背後にあるセキュリティで保護されたサーバーにのみ存在すると仮定します。 DBでのパスワードのマイナーな面倒は、それが提供する本質的に無料のセキュリティのために支払うための小さな価格です。
セルジュバレスタの答えを補完するものとして。
NoSQLデータベースを使用している場合、これは特にトリッキーになります。 MongoDB。デフォルトでは、すべてのデータベースユーザーがすべてのデータベースに対してread-only権限を持ち、db-userそのまま使用できます。 Spider Labs Blog が少し前（2013年頃）に述べているように、かなりの弱点がありますが、大企業（例： MacKeeper インシデント（2015年後半）。
どちらのリファレンスにも、最も一般的な脆弱性のリストがあります。 「公式」のガイドラインを読みたければ、それらを見つけることができます here 、それらはSQLデータベースに類似しています。ただ、安全がテーマならやり過ぎはないと思いたい。