DBサーバーが危険にさらされた場合に、不正なログインを保護するにはどうすればよいですか？
一般に、ユーザーがWebアプリに登録すると何が起こるかというと、パスワードがうまくハッシュされるため、DBリークが発生しても、元のパスワードを取得することは不可能です。
しかし、攻撃者（または悪意のあるsysadmin）がDBおよびAPPサーバーにアクセスし、データをダンプする代わりに、ハッシュ/ソルティングを実行するコードを探し、その知識で新しいハッシュを偽造し、単純に、 DBの適切なフィールド内にドロップしますか？
これは非常にまれなシナリオであることは知っていますが、これからユーザーアカウントを保護する業界標準の方法はありますか？
説明：攻撃者は、APPサーバーへの読み取り専用アクセスと、DBへの読み取り/書き込み権限しか持っていません。
事実上、攻撃者がしているのはユーザーのパスワードを変更することだけです。これにより、攻撃者はこれらのユーザーのアカウントにログインすることができます。これからどのように保護するかについては、気にする必要があるかどうかはわかりません。誰かがDBへの読み取り/書き込みアクセス権を持っている場合、あなたはかなり沈んでいます。そもそも、誰かがDBへの読み取り/書き込みアクセス権を取得するのを防ぐ必要があります。書き込みアクセス権を持つユーザーが誰かのパスワードを変更することを防ぐのではありません。
これは、誰かがあなたの家に侵入した場合に、冷蔵庫を開けてビールを盗まないようにするにはどうすればいいのかと思います。
あなたの質問は次のように言い換えることができます：
データを変更するアクセス権を持つユーザーがデータを変更しないようにするにはどうすればよいですか？
最初のステップは、アクセスを期待されている人だけがアクセスできるようにすることです。これは、適切なパスワード管理の実践とアカウント監査（ある時点でアクセス権を期待されている人）であり、アクセス権のない人、定期的なパッチ適用、コード検査、ペンのテストを防ぐためです。
しかし、システム管理者がおかしくならないようにすることはできません（給与や労働条件などは別として）。システムが完全に安全であることを証明することはできません。しかし、そのような活動を防止または阻止するためにできることはまだあります。
従来の3層ウェブアプリには、データベースに接続するアプリケーション層にサービスアカウントがあります。このアカウントが操作対象のデータを含むすべてのテーブルへの読み取り/書き込みアクセス権を持っている（そして過去に書かれた）アプリを頻繁に見ました。ストアドプロシージャを使用して、読み取り操作と書き込み操作を特定のレコードに制限することで、ある程度の緩和策が提供されます。
補足的なアプローチは、単にユーザー資格情報の検証をゲートウェイテストとして扱うのではなく、エンドユーザーが提供する資格情報に依存して、アプリケーション層からデータベースへの認証を行うことです。最も単純な場合、エンドユーザーはデータベースユーザーとして作成され、アプリケーションは接続する必要があるたびに資格情報を保存します。ただし、このアプローチにはスケーラビリティの問題があります。特にOracleの場合、おしゃべりな認証プロセスがあり、Oracle上のほとんどのアプリで永続的な接続が再利用されます。追加の制御がない場合、エンドユーザーのパスワードはクリアテキストのサービスパスワードだけでなく、クリアテキストで保存されます（ただし、これには解決策があります）。
インシデントを防ぐためにできることをすべて行った後のパズルのもう1つの重要な部分は、検出です。重要なデータが変更されたときにクライアントの識別子（IPアドレス）をキャプチャする：データベースに送信されるクエリとDMLをキャプチャし、監査：ハニーポット/カナリアデータのデプロイ
私はあなたができないと思います-彼らがアプリサーバーの制御権を持っている場合、彼らはパスワードチェックを完全にバイパスするようにパッチを当てることができます。
ハッシュのポイントは、漏えいしたデータベースからオンラインアカウントへのアクセスを困難にすることです。また、ユーザーがサービス間で共有しているパスワードを抽出することは困難です。
ライブデータベースのみを変更できる（アプリサーバーは変更できない）場合、ハッシュに「ペッパー」を追加すると、ハッシュを独自のものに置き換えることができなくなる可能性があります。
あなたが説明するシナリオは、攻撃者がユーザーのパスワードを自分のパスワードに置き換えることができる場合よりもはるかに悪いです。ユーザーが自分のアプリケーションコードを変更できれば、ユーザーが望むことは何でもできるのです。パスワードの再利用により、プレーンテキストのパスワードが公開されることも心配になります。
アプリケーションのコードを信頼できなくなった場合は、すでに完全に失っています。残された唯一のことは 軌道からそれを核にする です。
編集：攻撃者がアプリケーションコードを変更できないことが判明したため、プレーンテキストのパスワードを盗むことはできませんが、おそらくできるのでアプリがデータベースを直接編集することで許可されているほとんどのことは、たとえ可能であったとしても、パスワードを置き換えることを防ぐ価値はないと思われます。
新しいハッシュを適切なフィールドにドロップする背後にある意図が正確に理解できませんでした。また、パスワード、ユーザーデータ、または暗号化を異なる方法で処理するdb-systemsがたくさんあるので、それが一般的にどのようであるかを説明することはできません。以下のオプションは、（postgresql）で使用するdbシステムで使用できます。
- パスワードはクライアント側でハッシュされ、サーバー上では平易ではありません
- パスワードは接続ごとにソルトを取得して、ハッシュをキャプチャして以降のセッションで使用しないようにします
- 証明書ベースの暗号化
- 列またはファイルシステムレベルでの通常のデータ暗号化
- クライアント側の暗号化により、データが暗号化されずにサーバーに到達するのを防ぎます
これらの予防策により、十分に保護する必要があります。ただし、これは、指定しなかったデータベースとクライアント（Webアプリ）によって異なります。
セキュリティ監視
データベース内のすべてを監視し、ユーザーがデータベース内で情報を変更したりスクリプトを実行したりするときに警告を作成できるツールを展開できます。これらのツールのほとんどは、データベースへのユーザーログオンよりも瞬時にレポートし、すべてのスクリプトとプロシージャが変更/実行されます中の彼の時間の間に。
DB管理者はデータベースにアクセスできますが、情報/テーブル/スクリプトは完全に制限する必要があります。
どのように保護できますか？
データベースへの従業員のアクセス、およびスクリプトと手順の実行のために、異なるアプローチまたは手順を実装します。
DB管理者はデータベースにアクセスできますが、付与するアクセスは完全なDBではなく、主にメンテナンスに焦点を当てた特定の目的のためだけです。
さらに多くのオプションを利用できるDB内の別のユーザーの資格情報を情報セキュリティに要求できますが、それらのオプションの重要度によっては、より多くのプロセスを定義できます。
- そのアクセスを許可するためのさまざまな人々からの多くの承認。
- あなたがあなたの仕事をしている間、セキュリティの誰かがあなたと一緒にいます。
- スーパーユーザーとの作業を開始した時点からの復元ポイント。
- パスワードは1回限りの使用で、一度使用すると破棄されます
上記の答えは正解です。DBサーバーとアプリサーバーにアクセスできる場合は、主にゲームオーバーです。
ただし、ユーザーのパスワードを変更するという非常に具体的な質問に関しては、@ TTTがうまくまとめています。
事実上、攻撃者がしているのはユーザーのパスワードを変更することだけです。これにより、攻撃者はこれらのユーザーのアカウントにログインすることができます。
これは本当です
これからどのように保護するかについては、気にする必要があるかどうかはわかりません。
ここで可能な保護は1つです。2要素認証を実装します。これはDBを保護するものではありませんが、パスワードを変更するだけでは、そのユーザーとしてログインするには不十分です。
さて、この状況ではおそらく役に立たないでしょう。もしアプリサーバーとDBサーバーへのフルアクセス権があれば、おそらく2FAを無効にするか、攻撃者が制御するものに変更できます。しかし、誰かがパスワードハッシュを変更することから保護するという点では（元の質問の最も狭い読み方）、これによりある程度保護されます。攻撃者と実際のユーザーの両方が最終的にロックアウトされることに注意してください（1つはパスワードを知っていて、もう1つは2要素のチャレンジに答えることができます）。
もちろん、2FAを実装する他のより良い理由があります（より可能性の高い攻撃ベクトル（まだ「ゲームオーバー」になっていないもの）を防ぐという意味で「より良い」）。