次の方法で共有

セキュリティ制御 v3: ID 管理

  • [アーティクル]

Identity Management では、アプリケーション、条件付きアクセス、アカウントの異常監視にシングル サインオン、強力な認証、マネージド ID (およびサービス プリンシパル) の使用など、Azure Active Directory を使用してセキュリティで保護された ID とアクセス制御を確立するための制御について説明します。

IM-1: 一元的な ID および認証システムを使用する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.7、12.5 AC-2、AC-3、IA-2、IA-8 7.2、8.3

セキュリティ原則: 一元的な ID と認証システムを使用して、クラウド リソースと非クラウド リソースに対する組織の ID と認証を管理します。

Azure ガイダンス: Azure Active Directory (Azure AD) は、Azure の ID および認証管理サービスです。 以下で組織の ID および認証を管理するには、Azure AD を標準化する必要があります。

  • Azure Storage、Azure Virtual Machines (Linux と Windows)、Azure Key Vault、PaaS、SaaS アプリケーションなどの Microsoft Cloud リソース。
  • Azure 上のアプリケーション、企業ネットワーク リソースで実行されているサード パーティのアプリケーション、サード パーティの SaaS アプリケーションなどの組織のリソース。
  • 一貫性のある一元的に管理された ID 戦略を確保するために、Azure AD への同期による Active Directory の企業 ID。

注: 技術的に実現できるようになったらすぐに、オンプレミスの Active Directory ベースのアプリケーションを Azure AD に移行する必要があります。 これには、Azure AD エンタープライズ ディレクトリ、企業間の構成、または企業-消費者間の構成があります。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-2: ID および認証システムを保護する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
5.4、6.5 AC-2、AC-3、IA-2、IA-8、SI-4 8.2、8.3

セキュリティ原則: 組織のクラウド セキュリティ プラクティスで、ID および認証システムを高優先度としてセキュリティで保護します。 共通のセキュリティ コントロールには、次が含まれます。

  • 特権ロールとアカウントを制限する
  • すべての特権アクセスに対して強力な認証を要求する
  • リスクの高いアクティビティを監視および監査する

Azure ガイダンス: Azure AD セキュリティ ベースラインと Azure AD ID セキュリティ スコアを使用して、Azure AD ID のセキュリティ態勢を評価し、セキュリティと構成のギャップを修復します。 Azure AD ID セキュリティ スコアでは、次の構成の Azure AD を評価します。-制限のある管理者ロールを使用する

  • ユーザー リスク ポリシーをオンにする
  • 複数のグローバル管理者を指定する
  • レガシ認証をブロックするポリシーを有効にする
  • すべてのユーザーがセキュリティで保護されたアクセスのために多要素認証を完了できるようにする
  • 管理者ロールに対して MFA を必須にする
  • セルフサービス パスワード リセットを有効にする
  • パスワードを有効期限切れにしない
  • サインイン リスク ポリシーをオンにする
  • アンマネージド アプリケーションへの同意をユーザーに許可しない

注: オンプレミスの Active Directory とサード パーティの機能を含むその他すべての ID コンポーネントと、これらをホストするインフラストラクチャ (オペレーティング システム、ネットワーク、データベースなど) に関する、公開されているベスト プラクティスに従ってください。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-3: アプリケーション ID を安全かつ自動的に管理する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
なし AC-2、AC-3、IA-4、IA-5、IA-9 なし

セキュリティ原則: アプリケーションでリソースにアクセスしてコードを実行するための人間のアカウントを作成する代わりに、マネージド アプリケーション ID を使用します。 マネージド アプリケーション ID では、資格情報の公開を減らすなどの利点を提供します。 ID のセキュリティを確保するために、資格情報のローテーションを自動化します。

Azure ガイダンス: Azure マネージド ID を使用します。Azure AD 認証をサポートする Azure のサービスとリソースに対して認証を行うことができます。 マネージド ID の資格情報は、プラットフォームによって完全に管理、ローテーション、保護されており、ソース コードまたは構成ファイル内でハードコーディングされた資格情報を使用せずに済みます。

マネージド ID をサポートしていないサービスの場合、Azure AD を使用して、リソース レベルでアクセス許可が制限されたサービス プリンシパルを作成します。 証明書の資格情報を使用してサービス プリンシパルを構成し、認証のためにクライアント シークレットにフォールバックすることをお勧めします。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-4: サーバーとサービスを認証する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
該当なし IA-9 該当なし

セキュリティ原則: クライアント側からリモート サーバーとサービスを認証し、信頼されたサーバーおよびサービスに接続していることを確認します。 最も一般的なサーバー認証プロトコルは、トランスポート層セキュリティ (TLS) です。クライアント側 (多くの場合、ブラウザーまたはクライアント デバイス) では、サーバーの証明書が信頼された証明機関によって発行されたことを確認することによってサーバーを検証します。

注: サーバーとクライアントの両方で相互に認証する場合に相互認証を使用できます。

Azure ガイダンス: 多くの Azure サービスでは、TLS 認証が既定でサポートされています。 ユーザーによる TLS の有効化/無効化の切り替えをサポートするサービスでは、サーバー/サービス認証をサポートするために常に有効になっていることを確認してください。 また、クライアント アプリケーションは、ハンドシェイク段階で (信頼された証明機関によって発行されたサーバーの証明書を確認することによって) サーバー/サービス ID を確認するように設計する必要があります。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-5: アプリケーション アクセスにシングル サインオン (SSO) を使用する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
12.5 IA-4、IA-2、IA-8 なし

セキュリティ原則: シングル サインオン (SSO) を使用して、クラウド サービスとオンプレミス環境全体でアプリケーションやデータなどのリソースに対する認証のユーザー エクスペリエンスを簡略化します。

Azure ガイダンス: Azure AD シングルサインオン (SSO) を介したワークロード アプリケーションへのアクセスに Azure AD を使用します。複数のアカウントは必要はありません。 Azure AD では、Azure リソース (CLI、PowerShell、ポータルなどの管理プレーン)、クラウド アプリケーション、オンプレミス アプリケーションに対する ID とアクセスの管理を提供します。

Azure AD では、企業ユーザー ID などのエンタープライズ ID や、信頼されたサード パーティおよびパブリック ユーザーからの外部ユーザー ID について SSO をサポートします。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-6: 強力な認証制御を使用する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.3、6.4 AC-2、AC-3、IA-2、IA-5、IA-8 7.2、8.2、8.3、8.4

セキュリティ原則: リソースへのすべてのアクセスについて、一元化された ID と認証管理システムを使用して、強力な認証制御 (強力なパスワードレス認証または多要素認証) を適用します。 パスワード資格情報だけに基づく認証は、安全ではなく一般的な攻撃方法に耐えるものではないため、レガシと見なされます。

強力な認証をデプロイする場合は、最高レベルの強力な認証方法を確保するために、まず管理者と特権ユーザーを構成し、その後すぐに、適切な強力な認証ポリシーをすべてのユーザーにロールアウトします。

注: レガシ アプリケーションとシナリオで従来のパスワード ベースの認証が必要な場合は、複雑さの要件などのパスワード セキュリティのベスト プラクティスに必ず従ってください。

Azure ガイダンス: Azure AD では、パスワードレスの方法と多要素認証 (MFA) によって、強力な認証制御がサポートされています。

  • パスワードレス認証: 既定の認証方法としてパスワードレス認証を使用します。 パスワードレス認証で使用できるオプションには、Windows Hello for Business、Microsoft Authenticator アプリの電話でのサインイン、FIDO 2keys の 3 つがあります。 また、顧客はスマート カードなどのオンプレミスの認証方法を使用することもできます。
  • 多要素認証: Azure MFA は、すべてのユーザー、選択されたユーザー、またはサインインの条件とリスク要因に基づいてユーザーごとのレベルで適用できます。 Azure MFA を有効にして、MFA の設定に関する Microsoft Defender for Cloud ID とアクセス管理の推奨事項に従います。

Azure AD 認証に従来のパスワード ベースの認証がまだ使用されている場合は、クラウド専用アカウント (Azure で直接作成されたユーザー アカウント) では既定のベースライン パスワード ポリシーが使用されていることに注意してください。 また、ハイブリッド アカウント (オンプレミスの Active Directory から取得したユーザー アカウント) は、オンプレミスのパスワード ポリシーに従います。

既定の ID とパスワードが使用されている可能性のあるサード パーティ製のアプリケーションやサービスの場合は、サービスの初期設定時にそれを無効にするか変更する必要があります。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-7: 条件に基づいてリソースへのアクセスを制限する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
3.3、6.4、13.5 AC-2、AC-3、AC-6 7.2

セキュリティ原則: ゼロトラスト アクセス モデルの一部として、リソースへのユーザー アクセスを許可または拒否するために、信頼されたシグナルを明示的に検証します。 検証するシグナルには、ユーザー アカウントの強力な認証、ユーザー アカウントの行動分析、デバイスの信頼性、ユーザーまたはグループのメンバーシップ、場所などが含まれている必要があります。

Azure ガイダンス: 特定の IP 範囲 (またはデバイス) からのユーザー ログインに対する MFA の使用の要求など、ユーザー定義の条件に基づく、より詳細なアクセス制御のために、Azure AD の条件付きアクセスを使用します。 Azure AD 条件付きアクセスによって、組織のアプリに対するアクセス制御を一定の条件に基づいて適用できます。

ワークロードで Azure AD 条件付きアクセスに適用できる条件を定義します。 次の一般的なユース ケースを考えてみましょう。

  • 管理者の役割を持つユーザーに多要素認証を要求する
  • Azure 管理タスクに対して多要素認証を要求する
  • レガシ認証プロトコルを使用しようとしているユーザーのサインインをブロックする
  • Azure AD Multi-Factor Authentication の登録に信頼できる場所を要求する
  • 特定の場所からのアクセスをブロックまたは許可する
  • リスクの高いサインイン動作をブロックする
  • 特定のアプリケーションに対して、組織のマネージド デバイスを必要とする

注: 詳細な認証セッション管理は、サインインの頻度や永続的なブラウザー セッションなどのコントロールに対して、Azure AD 条件付きアクセス ポリシーを通じて使用することもできます。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-8: 資格情報とシークレットの公開を制限する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
16.9、16.12 IA-5 3.5、6.3、8.2

セキュリティ原則: アプリケーション開発者が資格情報とシークレットを安全に処理できるようにします。

  • 資格情報とシークレットをコードおよび構成ファイルに埋め込まないようにする
  • キー コンテナーまたはセキュリティで保護されたキー ストア サービスを使用して、資格情報とシークレットを格納する
  • ソース コードで資格情報をスキャンする。

注: これは多くの場合、セキュリティで保護されたソフトウェア開発ライフサイクル (SDLC) と DevOps セキュリティ プロセスによって管理および適用されます。

Azure ガイダンス: シークレットと資格情報が、コードと構成ファイルに埋め込まれるのではなく、Azure Key Vault などの安全な場所に格納されていることを確認します。

  • コード内で資格情報を特定する Azure DevOps 資格情報スキャナーを実装します。
  • GitHub の場合、ネイティブ シークレット スキャン機能を使用して、コード内で資格情報やその他の形式のシークレットを識別します。

Azure Functions、Azure アプリ サービス、VM などのクライアントでは、マネージド ID を使用して Azure Key Vault に安全にアクセスできます。 シークレット管理については、Azure Key Vault の使用に関連するデータ保護のコントロールを参照してください。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):

IM-9: 既存のアプリケーションへのユーザー アクセスをセキュリティで保護する

CIS コントロール v8 ID NNIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
6.7、12.5 AC-2、AC-3、SC-11 なし

セキュリティ原則: レガシ認証を使用するオンプレミスのアプリケーションまたはネイティブでないクラウド アプリケーションがあるハイブリッド環境では、次のような利点を得られるこれらのアプリケーションへのアクセスを管理するために、クラウド アクセス セキュリティ ブローカー (CASB)、アプリケーション プロキシ、シングル サインオン (SSO) などのソリューションを検討します。

  • 一元化された強力な認証を適用する
  • 危険なエンド ユーザー アクティビティを監視および制御する
  • 危険なレガシ アプリケーションのアクティビティを監視および修復する
  • 機密データの送信を検出して防止する

Azure ガイダンス: レガシ認証を使用して、オンプレミスとネイティブではないクラウド アプリケーションを次のものに接続して、これらを保護します。

  • Azure AD アプリケーション プロキシをヘッダーベースの認証と組み合わせて、Azure AD 条件付きアクセスを使用してリモート ユーザーとデバイスの両方の信頼性を明示的に検証しながら、シングル サインオン (SSO) を使用してリモート ユーザーにレガシ オンプレミス アプリケーションを発行することができます。 必要に応じて、同様の機能を提供できる、サード パーティの Software-Defined Perimeter (SDP) ソリューションを使用します。
  • 既存のサード パーティのアプリケーション デリバリー コントローラーおよびネットワーク
  • Microsoft Defender for Cloud Apps、クラウド アクセス セキュリティ ブローカー (CASB) サービスとして使用して、ユーザーのアプリケーション セッションを監視し、アクションをブロックするための制御を提供します (従来のオンプレミス アプリケーションとサービスとしてのクラウド ソフトウェア (SaaS) アプリケーションの両方)。

注: レガシ アプリケーションへのアクセスには VPN がよく使用されますが、多くの場合、基本的なアクセス制御と限られたセッション監視しか行われません。

実装と追加コンテキスト:

顧客のセキュリティ上の利害関係者 (詳細):