次の方法で共有

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

  • [アーティクル]

ID 管理では、シングル サインオンの使用、強力な認証、アプリケーションのマネージド ID (およびサービス プリンシパル)、条件付きアクセス、アカウント異常監視など、ID とアクセス管理システムを使ってセキュリティで保護された 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 と認証システムを使用して、クラウドリソースと非クラウド リソースに対するorganizationの 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 クラウド リソース。
  • Azure 上のアプリケーション、企業ネットワーク リソースで実行されているサード パーティのアプリケーション、サード パーティの SaaS アプリケーションなどの組織のリソース。
  • 一貫性のある一元的に管理された ID 戦略を確保するために、Azure AD への同期による Active Directory の企業 ID。

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

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

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 Directory Sync の使用。Google は、ほとんどのエンタープライズ LDAP 管理システムと統合し、スケジュールに従って ID を同期するコネクタ ツールを提供します。 クラウド ID アカウントを構成し、Google Cloud Directory Sync を歌うことで、ローカル ID 管理システムと GCP システムの間でスケジュールに従って同期するユーザー アカウント (ユーザー、グループ、ユーザー プロファイル、エイリアスなど) を構成できます。

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

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

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

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

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

Azure ガイダンス: Azure AD セキュリティ ベースラインと Azure AD ID セキュリティ スコアを使用して、Azure AD ID のセキュリティ体制を評価し、セキュリティと構成のギャップを修復します。 Azure AD Identity Secure Score では、次の構成について 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 および Cloud Identity サービスにセキュリティで保護します。

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

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

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

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

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

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 は、定義された条件に基づいて、すべてのユーザーに適用したり、ユーザーを選択したり、ユーザーごとのレベルで適用したりできます。 Cloud Identity (および Workspace) のスーパー管理者アカウントを保護するには、セキュリティ キーと Google Advanced Protection プログラムを使用して最大限のセキュリティを確保することを検討してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 アプリケーション プロキシし、リモート ユーザーのアプリケーションへのシングル サインオン (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 境界 (SDP) ソリューションを使用します。
  • Microsoft Defender for Cloud Apps。未承認のサードパーティ SaaS アプリケーションへのユーザー アクセスを監視およびブロックするためのクラウド アクセス セキュリティ ブローカー (CASB) サービスとして機能します。
  • 既存のサード パーティのアプリケーション デリバリー コントローラーおよびネットワーク

注: 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 の実装と追加のコンテキスト:

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