内部攻撃者の場合の役に立たない2FA
ユーザーキーがHSMで生成され、データベースにエクスポートされ、ユーザーパスワードとHSMのマスターキーから派生した対称キーで暗号化されるサーバー側の署名シナリオを想定します。
署名するには、ユーザーは参照されたパスワードと、たとえばOTPなどの追加要素を提供する必要があります。 OTPは動的な値であるため、キーを保護するために使用することはできません。そのため、OTPは認証バリアとしてのみ使用されます。 2つの要素の送信はSSLを介して行われます。
ここで、悪意のある内部攻撃者がアプリケーションコードを変更し、ユーザーが送信したパスワードがファイルに記録されると想像してみてください。
アプリケーションを介した署名操作には2つの要素が必要ですが、外部の攻撃者からの攻撃をある程度防ぐことができます。内部の攻撃者がHSMに直接アクセスし、パスワードを使用して署名キーを復号化し、それを使用してユーザーに代わってドキュメントに署名することを防ぐにはどうすればよいですか。 ？
通常、HSMへの物理アクセスは二重制御によって保護されますが、リモートでログインするためのパスワードを持っている場合、ユーザーはHSMに論理的にアクセスできます。
このような内部攻撃を防ぐために、どのようなセキュリティ対策を講じることができますか？
監査と警告は、内部脅威に対する一般的なアプローチです。
機密性の高いシステムでのアクティビティが大量にログに記録され、監視されていることを確認すると、それらのシステムを破壊することの難しさが劇的に高まります。通常、ログオンをログに記録して警告し、システムで実行されたすべてのアクションの監査ログを維持します。これらのログを改ざんから保護するには、機密システムのユーザーがアクセスできないライトワンスメディアまたは別のシステムにログを送信します。
この問題に対するもう1つの効果的で比較的安価なアプローチは、4つの目の原則です（特定のアクションを監視するために2人が必要です）。
最後に、コード（または他のファイル）の整合性が心配な場合は、いつでもコード署名を利用できます。変更が心配なものに暗号署名を添付すると、コードが許可なく変更されないという非常に高い確実性が得られます（もちろん、その署名システムのセットアップのPKIを適切に取得していると仮定します）。 。
おそらくあなたはこれを考えすぎています。あなたが言う時：
ここで、悪意のある内部攻撃者がアプリケーションコードを変更すると想像してください...
次に、アプリケーションコードが何に変更されるかを推測し、その特定の変更に対する解決策を考え出そうとしています。問題は、そもそもコードを変更できれば、他の多くのことも実行できるようにコードを変更できることです。そのほとんどは予測できません。したがって、ある変更から保護しても、別の変更からは保護されない可能性があります。
内部攻撃から保護するために講じるセキュリティ対策は、最初にアプリケーションコードを変更するためのアクセス権を持つユーザーを制限し、通知システムを導入して、変更されたかどうか、誰が変更したかをすぐに把握できるようにすることです。