サービスアカウントで2FAを有効にする必要がありますか？
タイトルを見てください。私は現在セキュリティ監査に関与しており、2FAを人間のログインアカウントだけでなくサービスアカウント（非人間のアカウント）でも有効にする必要があるかどうか疑問に思っていますか？もしそうなら、これは通常どのように管理されますか？ 2FAの権利を確認するには、誰かがまだ反対側にいる必要がありますか？そして、これは主にセットアップ時の一時的なものですか、それとも定期的に2FAリクエストを再確認する必要がありますか？
サービスアカウントでMFAを要求する際の問題は、完全に自動化する必要があることです。たとえば、 時間ベースのOTP です。
ただし、このOTPはシークレットシードに基づいているため、事実上、サービスアカウントが使用できる構成に保存されている別のパスワードにすぎません。そのため、パスワードなどの単一の要素のセキュリティを超える実際の追加のセキュリティは提供されません。
多要素認証は確かに人間の介入なしに可能です。
ただし、フレームチャレンジが必要です。
人間を扱う場合、認証の3つの典型的な要素は知っているもの（パスワード）、あなたが持っているもの（TOTPデバイス/プログラム、SMS付き電話、電子メールへのアクセス）です。アカウントなど）、そしてあなたが何か（生体認証）。同じ要素の異なるものを組み合わせて、多要素認証と呼ぶことはできません。つまり、指紋と網膜スキャンは2FAではなく、指紋とパスワードは2FAです。
生体認証は、人間の指紋をスキャンしている場合でも、コンピューターを「指紋で」検出している場合でも、信頼できるエージェントが待機していない限りクライアントが嘘をついていないことを確認できないため、ネットワークでは機能しません。 「クライアントは敵の手中にある。」 -Raph Koster（セキュリティエキスパートではなくゲームデザイナーですが、アドバイスは適切に適用されます。）信頼できるエージェントがいない場合、バイオメトリクスは識別（*）ではなく、識別にのみ役立ちます。
次の認証要素は、あなたが持っているものですが、通常はコンピュータのときに知っているものと区別がつきません。 TOTPシード、パスワード、セッショントークン、RSA秘密鍵などは、コンピューターにとっては単なるバイトであり、ある時点でRAMに常駐します。人間はTOTPシード、セッショントークン、暗号化キーなどを2番目の要素にすることで問題を回避できます。人間はこれらを記憶することができないため、別個のハードウェア（または少なくとも書き留めたもの）にアクセスする必要があるためです。
ただし、コンピュータが前もって「知る」ことができないものがあります。 U2Fドングルなど、暗号化操作を実行し、コピーできない方法（改ざんの明白な証拠がない場合）で秘密鍵を内部に格納するハードウェアデバイスがある場合、これはコンピューターにあるものとして認定されますが、そうではありません。知っている。同様に、帯域外で送信される情報も、コンピューターが知っているものではなく、コンピューターが持っているものと見なすことができます。たとえば、トークンを電子メールで送信したり、FTPで送信したり、SMS経由で送信したりできます。脅威モデルによっては、別のポートで接続を開くだけで自動監視ツールをだますのに十分かもしれませんが、私はアクティブな盗聴者に対してそれを信頼しません。
脅威モデルといえば、パスワードを使用するユーザーに対する現在の脅威モデルは、それがただ1つの要素であるという事実ではありません。脅威モデルは、ほとんどのユーザーがパスワードを再利用し、エントロピーパスワードが低く、ほとんどすべての人間のデータが、検出または報告されていない多くのデータ侵害を含む複数のデータ侵害に含まれていることです。コンピューターは非常に長く、真にランダムなパスワードを記憶するのに問題がなく、与えられたすべてのパスワードを記憶できるため、すべてのサービスアカウントに一意の高エントロピーパスワードを設定するのは簡単です。
脚注：
（*）身分証明書は認証とは異なり、火星の女王として自分を識別できますが、火星の女王として認証されません。ユーザー名は識別ですが、ユーザー名とパスワードは認証です。フィンガープリントは識別ですが、プロセスを監督する信頼できるエージェントで取得されるフィンガープリントは認証です。
「何か」としてのネットワークの場所
特定のアカウントへの自動接続が必要なサービスのセキュリティを向上させる1つの方法は、自動サービスがシステムAからシステムBに1日に2回接続する必要がある場合に、厳格なネットワーク制限で安全な認証（tls/sshクライアント証明書など）を強化することです、システムBはリクエストを認証するだけでなく、システムAのIPアドレスから送信されていないそのサービス/ポート/アカウントの接続を拒否する必要があります。
コピーできない資格情報
自動化サービスの秘密に取り組む別の方法は、それらをコピー不可にすることです。つまり、ビジネスロジックを実行しているソフトウェアには、これらの資格情報へのfullアクセスがなく、「署名システム」へのリンクしかありません。 'HSMまたは「ソフトウェアHSM」上で、通常、シークレットを抽出することはできませんが、使用方法は制限されています。その場合、メインシステムが危険にさらされても、後でシークレットを自由に使用してコピーすることはできず、リアルタイムでのみアクセスでき、ロギング、レート制限、その他の制限を回避することはできません。
サービスアカウントの2FAは必要ありません。実際に設定するのは面倒です。
100のようなサービスアカウントがあり、システムがシャットダウンして再認証が必要になるたびに、自分で2FAを毎回確認する必要があるとします。これを行わない場合、2FAは無意味。
サービスアカウントを保護する方法：
- パスワードを頻繁にローテーションします（パスワードを覚える必要のある人間はいないため、毎週ローテーションする可能性があります）。
- パスワードの複雑さを高くする（24文字以上の文字を使用できる可能性があります）
- Windows環境でWindowsサービスアカウントを使用している場合、このオプションは十分なセキュリティを提供します。 https://docs.Microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts
私はこれを要求した後の監査人が何であるか本当にわかりませんが、サービスアカウントがセキュリティで保護されていることの十分な証拠を監査人に提供する場合、問題ありません。
核心は、確かに問題のコンテキストでは、そのようなサービスアカウントに必要な保護のレベルは何ですか？リスクは何ですか？そして、これらをどのように軽減できますか？そして、監査の角度を考えると、そのトレードオフをどのように行ったかを示すことができますか？また、残っているリスクを追跡していますか？
私は通常、単純な俳優と脅威のモデルを作成します。稼働時間、例外的なケースでのアクセス、堅牢性、ガバナンス、組織の流動性など、機能以外の要件に特に注意を払います。
一般に、サービスアカウントは3つのブロックに分類されます。1）組織で広く使用されており、2FAやその他の複雑さのリスクが「共有」のリスクを上回り始める程度まで「パワー」を最小化できるもの秘密の'。 2）サービスのメンテナンス、アップグレード、および展開されないものであるため、日常的に非常に強力である人、および3）本当に最終的な/最後のリゾートの例外であり、まれに使用されているが、不注意による損失を防止したい場合-物事が悲惨なとき。
最初のクラスは、多くの場合、優れた監視、ガバナンス、および緩和策としてではないものを備えた共有秘密です。または、しっかりしたセキュリティを備えた何かの上に、安全性の高い要塞/ Webインターフェースを構築するように導きます。これにより、ごく一部の非常に特定のルーチン操作のみをトリガーできます。
3番目のクラスでは、脆弱性が問題となる極端な状況で動作する必要があるため、分析では2FAまたは類似の導入が非常に望ましくないことがよくあります。したがって、多くの場合、金庫の封筒でオフラインパスワードを使用して、情報開示と盗難のリスクを最小限に抑えます。そして、見返りに堅牢性（および検証/サーバー側のソルト/ハッシュ）を取得します。次に、これを物理的なガバナンスおよび監査プロセスと組み合わせます。
しかし、常に問題となっているのはその中間層です。非常に強力で、よく使用されます。そして、時には複数の人が。しかし、あなたは本当に詐欺師やそのレベルのアクセスの喪失を望んでいません。スタッフを変更する場合でも、特に、セキュリティ違反などについて学びます。
したがって、ここでのトレードオフは、2FAの「痛み」と使いやすさの間のトレードオフです。
私の経験では、ある種の2FA軽減が全体的なリスク評価に役立つことがよくあります。これにより、パスワードなどのサイクルを繰り返す必要性や、アクセスを広めすぎるリスクを排除しながら、クローン機能を全体的に損なう可能性があります。
一般的な解決策は、USBトークンまたはチップカード上の（場合によってはPINがなくても）x509またはSSHキーのセットです。これらは、認証を特定の時点と空間に固定します。
2FAは不可、クライアント証明書は可
Geir Emblemsvag 回答に従って、2FAは別のパスワードにすぎません。それはやや回避策です 肉袋 人間とその低エントロピーパスワード。
しかし、マシンは高速であり、機能する（またはそれ以上、する必要がある）すべてのアクセスで非常に高いエントロピーが発生します。データがプレーンテキストで渡されることはありません。
サーバー/サービスでのクライアント証明書の検証は、それを保証する方法です。それはデータが常に暗号化されていることを保証し、あなたは無料でサービス認証と識別を取得します。