次の方法で共有

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

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

IM-1: 一元化された ID と認証システムを使用する

CIS Controls v8 ID NIST 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 および認証管理サービスです。 Azure AD を標準化して、組織の ID と認証を以下で管理する必要があります。

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

適用される Azure サービスの場合は、ローカル認証方法の使用を避け、代わりに Azure Active Directory を使用してサービス認証を一元化します。

注: 技術的に可能になるとすぐに、オンプレミスの Active Directory ベースのアプリケーションを Azure AD に移行する必要があります。 これは、Azure AD Enterprise Directory、Business to Business の構成、または Business からコンシューマーへの構成です。

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

AWS ガイダンス: AWS IAM (Identity and Access Management) は、AWS の既定の ID および認証管理サービスです。 AWS IAM を使用して、AWS ID とアクセス管理を管理します。 または、AWS と Azure Single Sign-On (SSO) を使用して、Azure AD を使用して AWS の ID とアクセス制御を管理し、2 つのクラウド プラットフォームで重複するアカウントを個別に管理しないようにすることもできます。

AWS では、単一 Sign-On がサポートされています。これにより、企業のサードパーティ ID (Windows Active Directory や他の ID ストアなど) を AWS ID とブリッジして、AWS リソースにアクセスするための重複するアカウントを作成しないようにすることができます。

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

GCP ガイダンス: Google Cloud の ID およびアクセス管理 (IAM) システムは、Google Cloud の既定の ID および認証管理サービスであり、Google Cloud ID アカウントに使用されます。 Google Cloud IAM を使用して、GCP ID とアクセス管理を管理します。 または、Google Cloud Identity と Azure Sigle Sign-On (SSO) を使用して、Azure AD を使用して GCP の ID とアクセス制御を管理し、マルチクラウド環境で重複するアカウントを個別に管理しないようにすることもできます。

Google Cloud Identity は、すべての Google サービスの ID プロバイダーです。 シングル Sign-On がサポートされています。これにより、会社のサード パーティの ID (Windows Active Directory や他の ID ストアなど) を Google Cloud ID とブリッジして、GCP リソースにアクセスするための重複するアカウントを作成しないようにすることができます。

注: Google Cloud ディレクトリ同期の使用。Google には、ほとんどのエンタープライズ LDAP 管理システムと統合し、スケジュールに従って ID を同期するコネクタ ツールが用意されています。 クラウド ID アカウントを構成し、Google Cloud Directory Sync を使用することで、ローカル ID 管理システムと GCP システムの間でスケジュールに従って同期するユーザー アカウント (ユーザー、グループ、ユーザー プロファイル、エイリアスなど) を構成できます。

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

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

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

CIS Controls v8 ID NIST 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 を要求する
  • セルフサービス パスワード リセットを有効にする
  • パスワードの有効期限を切らないでください
  • サインイン リスク ポリシーを有効にする
  • アンマネージド アプリケーションへの同意をユーザーに許可しない

Azure AD Identity Protection を使用して、ID ベースのリスクを検出、調査、修復します。 同様にオンプレミスの Active Directory ドメインを保護するには、Defender for Identity を使用します。

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

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

AWS ガイダンス: AWS IAM をセキュリティで保護するには、次のセキュリティのベスト プラクティスを使用します。

  • PA-5 (緊急アクセスの設定) で説明されているように、緊急アクセス用に AWS アカウントルートユーザーアクセスキーを設定する
  • アクセス割り当ての最小特権原則に従う
  • IAM グループを利用して、個々のユーザーではなくポリシーを適用します。
  • すべてのユーザーに対して IM-6 (強力な認証制御を使用する) の強力な認証ガイダンスに従う
  • AWS Organizations SCP (サービスコントロールポリシー) とアクセス許可の境界を使用する
  • IAM アクセス アドバイザーを使用してサービスアクセスを監査する
  • IAM 資格情報レポートを使用してユーザー アカウントと資格情報の状態を追跡する

注: 他の ID と認証システムがある場合は、公開されているベスト プラクティスに従ってください。たとえば、Azure AD を使用して AWS ID とアクセスを管理する場合は、Azure AD のセキュリティ ベースラインに従ってください。

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

GCP ガイダンス: 次のセキュリティのベスト プラクティスを使用して、組織の Google Cloud IAM およびクラウド ID サービスをセキュリティで保護します。

  • PA-5 の推奨事項 (「緊急アクセスの設定」) に従って、緊急アクセス用のスーパー管理者アカウントを設定します。
  • スーパー管理者のメール アドレス (Google ワークスペースまたは Cloud Identity スーパー管理者アカウントとして) を作成します。緊急回復が必要な場合、このアカウントは特定のユーザーに固有のものではありません。
  • 最小限の特権と職務の分離原則に従う
  • 毎日のアクティビティにスーパー管理者アカウントを使用しないようにする
  • Google Cloud ID グループを利用して、個々のユーザーにポリシーを適用するのではなく、ポリシーを適用します。
  • 昇格された特権を持つすべてのユーザーに対して IM-6 ("強力な認証制御を使用する") の説明に従って、強力な認証ガイダンスに従います。
  • IAM ポリシーを使用してリソースへのアクセスを制限する
  • 組織ポリシー サービスを使用してリソースの制約を制御および構成する
  • クラウド監査ログ内の IAM 監査ログを使用して特権アクティビティを確認する

注: 他の ID と認証システムがある場合は、公開されているベスト プラクティスに従ってください。たとえば、Azure AD を使用して GCP ID とアクセスを管理する場合は、Azure AD セキュリティ ベースラインに従ってください。

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

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

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

CIS Controls v8 ID NIST 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 AD 認証をサポートする Azure サービスとリソースに対して認証できる Azure マネージド ID を使用します。 マネージド ID 資格情報は、完全に管理され、ローテーションされ、プラットフォームによって保護されるため、ソース コードまたは構成ファイルでハードコーディングされた資格情報を回避できます。

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

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

AWS ガイダンス: この機能をサポートするリソースのユーザー アカウントを作成する代わりに、AWS IAM ロールを使用します。 IAM ロールはバックエンドのプラットフォームによって管理され、資格情報は一時的であり、自動的にローテーションされます。 これにより、ソース コードまたは構成ファイル内のアプリケーションとハードコーディングされた資格情報の長期的なアクセス キーまたはユーザー名/パスワードの作成が回避されます。

IAM ロールに対する独自のロールのアクセス許可をカスタマイズする代わりに、AWS サービス間のアクセスに事前に定義されたアクセス許可ポリシーがアタッチされているサービスにリンクされたロールを使用できます。

注: IAM ロールをサポートしていないサービスの場合は、アクセスキーを使用しますが、IM-8 キーをセキュリティで保護するために資格情報とシークレットの公開を制限するなどのセキュリティのベスト プラクティスに従ってください。

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

GCP ガイダンス: この機能をサポートするリソースのユーザー管理アカウントを作成する代わりに、Google が管理するサービス アカウントを使用します。 Google が管理するサービス アカウントは、バックエンドのプラットフォームによって管理され、サービス アカウント キーは一時的で自動的にローテーションされます。 これにより、アプリケーションの長期的なアクセス キーまたはユーザー名/パスワードの作成が回避され、ソース コードまたは構成ファイルにハードコーディングされた資格情報がハードコーディングされます。

ポリシー インテリジェンスを使用して、サービス アカウントの疑わしいアクティビティを理解し、認識します。

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

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

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

CIS Controls v8 ID NIST SP 800-53 r4 ID PCI-DSS ID v3.2.1
なし IA-9 なし

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

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

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

注: API Management や API Gateway などのサービスでは、TLS 相互認証がサポートされています。

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

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

注: API Gateway などのサービスでは、TLS 相互認証がサポートされています。

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

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

注: クラウド負荷分散などのサービスでは、TLS 相互認証がサポートされます。

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

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

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

CIS Controls v8 ID NIST 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 に対する SSO と、信頼されたサード パーティとパブリック ユーザーからの外部ユーザー ID もサポートされています。

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

AWS ガイダンス: AWS Cognito を使用して、シングル サインオン (SSO) を使用して顧客向けのアプリケーション ワークロードへのアクセスを管理し、顧客が異なる ID プロバイダーからサードパーティの ID をブリッジできるようにします。

AWS ネイティブ リソースへの SSO アクセス (AWS コンソール アクセスやサービス管理、データ プレーン レベルのアクセスを含む) には、AWS Sigle Sign-On を使用して、重複するアカウントの必要性を軽減します。

また、AWS SSO を使用すると、企業 ID (Azure Active Directory からの ID など) と AWS ID、および信頼されたサード パーティおよびパブリック ユーザーからの外部ユーザー ID をブリッジすることもできます。

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

GCP ガイダンス: Google Cloud Identity を使用して、Google Cloud Identity Single Sign-On を使用して顧客向けのワークロード アプリケーションへのアクセスを管理し、重複するアカウントの必要性を減らします。 Google Cloud Identity は、GCP (Google Cloud CLI、コンソール アクセスを含む管理プレーン内)、クラウド アプリケーション、オンプレミス アプリケーションに ID とアクセス管理を提供します。

また、Google Cloud Identity では、Azure AD や Active Directory からの企業ユーザー ID などのエンタープライズ ID に対する SSO と、信頼されたサード パーティおよびパブリック ユーザーからの外部ユーザー ID もサポートされています。 GCP の実装と追加のコンテキスト:

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

IM-6: 強力な認証コントロールを使用する

CIS Controls v8 ID NIST 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 アプリの電話によるサインイン、FIDO2 セキュリティ キーの 3 つのオプションがあります。 さらに、お客様はスマート カードなどのオンプレミスの認証方法を使用できます。
  • 多要素認証: Azure MFA は、サインイン条件とリスク要因に基づいて、すべてのユーザー、ユーザーの選択、またはユーザーごとのレベルで適用できます。 Azure MFA を有効にし、MFA のセットアップに関する Microsoft Defender for Cloud ID とアクセス管理の推奨事項に従います。

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

既定の ID とパスワードを持つ可能性があるサード パーティ製のアプリケーションとサービスの場合は、初期サービスのセットアップ時に無効にするか、変更する必要があります。

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

AWS ガイダンス: AWS IAM では、多要素認証 (MFA) による強力な認証制御がサポートされています。 MFA は、すべてのユーザーに適用するか、ユーザーを選択するか、定義された条件に基づいてユーザーごとのレベルで適用できます。

AWS ID でサードパーティのディレクトリ (Windows Active Directory など) の企業アカウントを使用する場合は、それぞれのセキュリティ ガイダンスに従って強力な認証を適用します。 Azure AD を使用して AWS アクセスを管理する場合は、このコントロールの Azure ガイダンスを参照してください。

注: 既定の ID とパスワードを持つ可能性があるサードパーティ製のアプリケーションと AWS サービスの場合は、サービスの初期セットアップ時に無効にするか、変更する必要があります。

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

GCP ガイダンス: Google Cloud Identity では、多要素認証 (MFA) による強力な認証制御がサポートされています。 MFA は、すべてのユーザーに適用するか、ユーザーを選択するか、定義された条件に基づいてユーザーごとのレベルで適用できます。 クラウド ID (およびワークスペース) のスーパー管理者アカウントを保護するには、セキュリティ キーと Google Advanced Protection Program を使用して最大のセキュリティを確保することを検討してください。

Google Cloud ID でサード パーティのディレクトリ (Windows Active Directory など) の企業アカウントを使用する場合は、それぞれのセキュリティ ガイダンスに従って強力な認証を適用します。 Azure AD を使用して Google Cloud アクセスを管理する場合は、このコントロールの Azure ガイダンスを参照してください。

Identity-Aware プロキシを使用して、HTTPS によってアクセスされるアプリケーションの中央承認レイヤーを確立します。そのため、ネットワーク レベルのファイアウォールに依存するのではなく、アプリケーション レベルのアクセス制御モデルを使用できます。

注: 既定の ID とパスワードを持つ可能性があるサード パーティ製アプリケーションおよび GCP サービスの場合は、初期サービスのセットアップ時に無効にするか、変更する必要があります。

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

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

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

CIS Controls v8 ID NIST 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 条件付きアクセス ポリシーを使用して実装することもできます。

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

AWS ガイダンス: IAM ポリシーを作成し、特定の IP 範囲 (またはデバイス) からのユーザー ログインに多要素認証の使用を要求するなど、ユーザー定義の条件に基づいてより詳細なアクセス制御の条件を定義します。 条件の設定には、ロジックだけでなく、単一または複数の条件が含まれる場合があります。

ポリシーは、ID ベースのポリシー、リソースベースのポリシー、アクセス許可の境界、AWS Organizations サービス制御ポリシー (SCP)、アクセス制御リスト (ACL)、セッション ポリシーの 6 つの異なるディメンションから定義できます。

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

GCP ガイダンス: 特定の IP 範囲 (またはデバイス) からのユーザー ログインに多要素認証の使用を要求するなど、ユーザー定義の条件に基づいて、より詳細な属性ベースのアクセス制御のための IAM 条件を作成および定義します。 条件の設定には、ロジックだけでなく、1 つまたは複数の条件が含まれる場合があります。

条件は、リソースの許可ポリシーのロール バインドで指定されます。 条件属性は、要求されたリソース (型や名前など) や要求に関する詳細 (タイムスタンプや宛先 IP アドレスなど) に基づいています。

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

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

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

CIS Controls v8 ID NIST 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 ガイダンス: マネージド ID を使用する場合は、シークレットと資格情報をコードファイルや構成ファイルに埋め込むのではなく、Azure Key Vault などのセキュリティで保護された場所に格納してください。

コード管理プラットフォームに Azure DevOps と GitHub を使用する場合:

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

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

注: Azure Key Vault では、サポートされているサービスの自動ローテーションが提供されます。 自動的にローテーションできないシークレットの場合は、手動で定期的にローテーションされ、使用されなくなったら消去されるようにします。

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

AWS ガイダンス: アプリケーション アクセスに IAM ロールを使用する場合は、シークレットと資格情報をコードファイルや構成ファイルに埋め込むのではなく、AWS Secret Manager や Systems Manager Parameter Store などの安全な場所に格納してください。

CodeGuru Reviewer を使用して、ソース コードでハードコーディングされたシークレットを検出できる静的コード分析を行います。

コード管理プラットフォームに Azure DevOps と GitHub を使用する場合:

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

注: Secrets Manager は、サポートされているサービスに対してシークレットの自動ローテーションを提供します。 自動的にローテーションできないシークレットの場合は、手動で定期的にローテーションされ、使用されなくなったら消去されるようにします。

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

GCP ガイダンス: アプリケーション アクセスに Google が管理するサービス アカウントを使用する場合は、シークレットと資格情報をコードファイルや構成ファイルに埋め込むのではなく、Google Cloud のシークレット マネージャーなどの安全な場所に保存してください。

Visual Studio Code などの IDE (統合開発環境) で Google Cloud Code 拡張機能を使用して、Secret Manager によって管理されるシークレットをコードに統合します。

コード管理プラットフォームに Azure DevOps または GitHub を使用する場合:

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

注: ベスト プラクティスとして Secret Manager に格納されているシークレットのローテーション スケジュールを設定します。

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

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

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

CIS Controls v8 ID NIST 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 アプリケーション プロキシとヘッダーベースの認証を構成して、リモート ユーザーのアプリケーションへのシングル サインオン (SSO) アクセスを許可すると同時に、Azure AD 条件付きアクセスを使用してリモート ユーザーとデバイスの両方の信頼性を明示的に検証します。 必要に応じて、同様の機能を提供できるサード パーティ製の Software-Defined Perimeter (SDP) ソリューションを使用します。
  • Microsoft Defender for Cloud Apps。クラウド アクセス セキュリティ ブローカー (CASB) サービスを提供し、承認されていないサード パーティの SaaS アプリケーションへのユーザー アクセスを監視およびブロックします。
  • 既存のサード パーティ製アプリケーション配信コントローラーとネットワーク。

注: VPN はレガシ アプリケーションにアクセスするために一般的に使用され、多くの場合、基本的なアクセス制御と制限付きセッション監視のみを使用します。

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

AWS ガイダンス: Azure のガイドラインに従い、レガシー認証を使用するオンプレミスと非ネイティブのクラウド アプリケーションを接続して保護してください。

  • Azure AD アプリケーション プロキシを構成し、リモート ユーザーのアプリケーションへのシングル サインオン (SSO) アクセスを許可するようにヘッダーベースを構成すると同時に、Azure AD 条件付きアクセスを使用してリモート ユーザーとデバイスの両方の信頼性を明示的に検証します。 必要に応じて、同様の機能を提供できるサード パーティ製の Software-Defined Perimeter (SDP) ソリューションを使用します。
  • Microsoft Defender for Cloud Apps。クラウド アクセス セキュリティ ブローカー (CASB) サービスとして機能し、承認されていないサード パーティの SaaS アプリケーションへのユーザー アクセスを監視およびブロックします。
  • 既存のサード パーティ製アプリケーション配信コントローラーとネットワーク

注: VPN はレガシ アプリケーションにアクセスするために一般的に使用され、多くの場合、基本的なアクセス制御と制限付きセッション監視のみを使用します。

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

GCP ガイダンス: Google Cloud Identity-Aware プロキシ (IAP) を使用して、オンプレミスのアプリケーションを含む、Google Cloud の外部にある HTTP ベースのアプリケーションへのアクセスを管理します。 IAP は、署名されたヘッダーまたはアプリ エンジンの標準環境内の Users API を使用して動作します。 必要に応じて、同様の機能を提供できるサードパーティ Software-Defined Perimeter (SDP) ソリューションを使用します。

また、クラウド アクセス セキュリティ ブローカー (CASB) サービスとして機能する Microsoft Defender for Cloud Apps を使用して、承認されていないサード パーティの SaaS アプリケーションへのユーザー アクセスを監視およびブロックすることもできます。

注: VPN は、レガシ アプリケーションにアクセスするために一般的に使用され、多くの場合、基本的なアクセス制御と制限付きセッション監視のみを使用します。

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

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