IAMの保護

セキュリティの推奨事項

Oracle Cloud Infrastructure Identity and Access Management (IAM)では、ユーザーの認証とリソース に対するアクセスの認可が提供されます。セキュリティに関連するIAMの概念は、次のとおりです:

IAMの概念と説明
概念 説明
コンパートメント コンパートメントは、リソースを論理グループにまとめるための基本的なメカニズムです。分離も提供します。
テナンシ Oracle Cloud Infrastructureは、組織によって作成されたアカウントについて自動的にテナンシを作成します。これは、組織のリソースをすべて含むルート・コンパートメントです。
ユーザーおよびグループ グループは、リソースのグループに対して同様のアクセス権を必要とするユーザーの集まりです。
リソース リソースは、Oracle Cloud Infrastructureサービスに作成されるオブジェクトです。
セキュリティ・ポリシー セキュリティ・ポリシーは、特定の集計レベルのリソースに対してIAMグループが保持するアクセスのタイプを指定します。集計レベルは、テナンシ、コンパートメントまたはサービスです。
動的グループ 動的グループを使用すると、プリンシパル・アクター(ユーザー・グループと同様)としてコンピュート・インスタンスを集計できます。これは、インスタンスによるOracle Cloud Infrastructure APIの呼出しを許可するために行います。
タグ タグを使用すると、レポートまたは一括処理のために、複数のコンパートメントにまたがるリソースを整理できます。
フェデレーション IAMと、組織がユーザーの認証に使用する他のアイデンティティ・プロバイダ(IdP)をフェデレートするメカニズム。

監査ログを定期的にモニターして、IAMのユーザー、グループおよびセキュリティ・ポリシーに対する変更を確認することをお薦めします。

IAMのテナンシおよびコンパートメント

  • コンパートメントはIAMで一意であり、エンタープライズ顧客が1つのアカウントすなわちテナンシを持つことによって主要なニーズを満たすためのメカニズムを提供します。この単一アカウントすなわちテナンシのおかげで、完全な集中管理と可視性が提供される一方で、構成チーム、プロジェクトおよびイニシアチブの必要性を満たすようにアカウントすなわちテナンシを分割することもできます。
  • セキュリティおよびガバナンスの理由から、ユーザーが必要とするリソースのみにアクセスできるようにしてください。たとえば、あるプロジェクトに取り組んでいるエンタープライズ・ユーザー、またはある業務部門に属するエンタープライズ・ユーザーは、そのプロジェクトまたは業務部門に属するリソースにのみアクセスできるようにする必要があります。コンパートメントは、アクセス権限に基づいてテナンシ・リソースをグループ化し、ユーザーのグループが必要に応じてコンパートメントにアクセスすることを認可する効果的なメカニズムを提供します。上の例では、業務部門に属するすべてのリソースを含めるコンパートメントを作成し、その業務部門のメンバーのみがそのコンパートメントにアクセスすることを認可します。同様に、コンパートメントへのグループのアクセス権は、不要になった場合に取り消すことができます。
  • コンパートメントを作成してリソースを割り当てるときには、次の点に注意してください:
    • すべてのリソースがコンパートメントに属している必要があります。
    • リソースは、作成後に別のコンパートメントに再割当てできます。コンパートメントの管理を参照してください。
    • コンパートメントは作成後に削除できます。コンパートメントの管理を参照してください。
  • リソース・タグは、複数のコンパートメントに分散されたリソースを論理的に集約する方法を提供します。たとえば、用途に応じてテナンシ・リソースにtestまたはproductionのタグを付けることができます。リソース・タグ(自由形式および定義済タグ)の詳細は、リソース・タグを参照してください。
  • すべてのテナンシには、デフォルトの管理者グループがあります。このグループは、テナンシのすべてのリソースに対してどのようなアクションでも実行できます(つまり、テナンシに対するルート・アクセス権を持ちます)。テナンシの管理者グループはできるだけ少人数にすることをお薦めします。テナンシ管理者を管理するためのセキュリティ推奨事項の一部:
    • テナンシ管理者グループのメンバーシップを付与するセキュリティ・ポリシーが、必要性の基準に厳密に従うようにします。
    • テナンシ管理者は、MFAとともに複雑度の高いパスワードを使用し、パスワードを定期的にローテーションする必要があります。
    • アカウントの設定と構成を行った後では、日常的な操作にテナンシ管理者アカウントを使用しないことをお薦めします。かわりに、権限を制限したユーザーとグループを作成してください。
    • 管理者アカウントは、日常業務では使用されませんが、顧客のテナンシおよび業務に影響を与える緊急シナリオに対処するために必要です。そのような緊急事態で管理者アカウントを使用するために、セキュアで監査可能な「非常時」用の手順を指定します。
    • 従業員が組織を離れるときにはテナンシ管理アクセス権を即座に無効化します。
    • テナンシ管理者グループのメンバーシップは制限されているため、管理者アカウントのロックアウトを防ぐセキュリティ・ポリシーを作成することをお薦めします(たとえば、テナンシ管理者が退職し、現在の従業員に管理者権限がない場合)。

IAMのユーザーおよびグループ

  • リソースへのアクセス権を必要とする顧客組織の全員に対してIAMユーザーを作成します。複数のユーザー間でIAMユーザー・アカウント(特に管理アカウントのユーザー)を共有しないでください。個別のIAMユーザーを使用することで、各ユーザーに対して最小限の権限アクセスを強制でき、監査ログで各ユーザーの操作を記録できます。
  • 推奨される管理単位はIAMグループです。これにより、(個々のユーザーの場合に比べて)セキュリティ権限の管理とトラッキングが容易になります。一般的に必要なタスク(たとえば、ネットワーク管理、ボリューム管理)を実行する権限を持つIAMグループを作成し、必要に応じてこれらのグループにユーザーを割り当てます。IAM権限を使用すると、テナンシの複数のコンパートメントにまたがるリソースに対するアクセスをグループに許可できます。
  • IAMグループ内のIAMユーザーのメンバーシップを定期的に確認し、アクセス権が必要なくなったIAMユーザーはグループから削除します。グループ・メンバーシップを使用したユーザー・アクセスの管理は、ユーザー数が増加しても適切に対応できます。
  • テナンシ・リソースへのアクセス権が不要になったIAMユーザーは非アクティブ化します。IAMユーザーを削除すると、そのユーザーが完全に削除されます。次の操作を実行することで、IAMユーザーを一時的に非アクティブ化できます:
    • ユーザー・パスワードをローテーションし、破棄します。
    • すべてのグループからユーザーのメンバーシップを削除することで、そのユーザーのテナンシに対するすべての権限を削除します。

IAMの資格証明

IAMユーザーの資格証明(コンソールのパスワード、API署名キー、認証トークンおよび顧客の秘密キー)によって、リソースへのアクセス権が付与されます。Oracle Cloud Infrastructureリソースへの不正アクセスを防ぐためには、これらの資格証明を保護することが重要です。資格証明を扱う際の一般的なガイドラインは、次のとおりです:

  • 各IAMユーザーに十分な複雑度の強力なコンソール・パスワードを作成します。パスワードを複雑にするために次のことをお薦めします:

    • パスワードの最小長は12文字です
    • パスワードに大文字を1文字以上含めます
    • パスワードに小文字を1文字以上含めます
    • パスワードに記号を1文字以上含めます
    • パスワードに数字を1文字以上含めます
  • IAMパスワードおよびAPIキーは定期的に90日以内にローテーションします。これは、セキュリティ設計のベスト・プラクティスというだけではなく、コンプライアンス要件でもあります。たとえば、PCI-DSSセクション3.6.4に、「キー管理手順に、使用中の各キー・タイプの暗号期間が定義されており、定義された暗号期間終了時のキーの変更プロセスが定義されていることを確認する」と定められています。
  • 機密性の高いIAM資格証明をソフトウェアにハード・コーディングしたり、広範なユーザーの目に触れる文書に記載したりしないでください。たとえば、GitHubにアップロードするコード、プレゼンテーションまたはインターネットでアクセスできるドキュメントなどです。意図せずに公開サイトで開示された資格証明をハッカーが使用して、顧客のクラウド・アカウントを侵害するケースは広く報道されています。ソフトウェア・アプリケーションがOracle Cloud Infrastructureリソースへのアクセスを必要とする場合は、インスタンス・プリンシパルの使用をお薦めします。インスタンス・プリンシパルの使用が実現できない場合は、ユーザー環境変数を使用して資格証明を格納したり、ローカルに格納された資格証明ファイルをAPIキーと一緒にOracle Cloud Infrastructure SDKまたはCLIで使用したりすることをかわりにお薦めします。
  • 複数のユーザー間でIAM資格証明を共有しないでください。
  • Oracle Identity Cloud Serviceを介してコンソール・ログインをフェデレートすることで、顧客は、IAMユーザー(特に管理者)のためにマルチファクタ認証(MFA)を使用できます。

APIキーをローテーションするときは、ローテーションしたキーが予期したとおりに動作することを確認してから、古いキーを無効にしてください。IAM APIキーの生成およびアップロードの詳細は、必要なキーとOCIDを参照してください。APIキーをローテーションするステップの概要は次のとおりです:

  1. 新しいAPIキーを生成し、アップロードします。
  2. SDKおよびCLIの構成ファイルを新しいAPIキーで更新します。
  3. SDKおよびCLIのコールが新しいキーで正しく動作することを確認します。
  4. 古いAPIキーを無効にします。ListApiKeysを使用して、すべてのアクティブなAPIキーをリスト表示します。

IAMのセキュリティ・ポリシー

IAMポリシーは、コンパートメントおよびテナンシ内のリソースへのIAMグループのアクセスを制御するために使用されます。リソースにアクセスするために最小限のアクセス権をIAMグループに割り当てることをお薦めします。IAMポリシーの一般的な形式を次の例に示します:

Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name>
Allow group <group_name> to <verb> <resource-type> in tenancy

IAMポリシーでは、事前定義済の4つの動詞(inspect、read、use、manage)を使用できます。inspectは最小限の権限、manageは最大限の権限を許可します。4つの動詞を権限が低い方から順に次の表に示します。

IAMポリシーの動詞
動詞 アクセス・タイプ ユーザー例
inspect メタデータのみを表示できます。通常、リソースのリスト表示のみが可能です サードパーティ監査者
read inspectに加え、リソースおよびユーザー・メタデータを読み取る権限が含まれます。これは、ほとんどのユーザーが業務を行うために必要な権限です。 内部監査者
use readに加えて、リソースを操作する権限が含まれます(操作はリソース・タイプによって異なります)。リソースを作成または削除する権限は含まれません テナンシのリソースおよびそれに対して実行されるアプリケーションの設定や構成を行う通常のユーザー(ソフトウェア開発者、システム・エンジニア、開発マネージャなど)
manage すべてのリソースに対するすべての権限 管理者、経営陣(非常時用シナリオ)

Oracle Cloud Infrastructureリソースのリソース・タイプを次の表に示します。

IAMリソース・ファミリ、説明およびリソース・タイプ
リソース・タイプ・ファミリ 説明 リソース・タイプ
all-resources すべてのリソース・タイプ  
名前なし(仕様) IAMサービスのリソース・タイプ compartmentsusersgroupsdynamic-groupspoliciesidentity-providerstenancy tag-namespacestag-definitions
instance-family コンピュート・サービスのリソース・タイプ console-historiesinstance-console-connectioninstance-imagesinstancesvolume-attachments
volume-family ブロック・ストレージ・サービスのリソース・タイプ volumesvolume-attachmentsvolume-backups
virtual-network-family 仮想ネットワーキング・サービスのリソース・タイプ vcnssubnetsroute-tablessecurity-listsdhcp-optionsprivate-ipspublic-ipsinternet-gatewayslocal-peering-gatewaysdrgsdeg-attachmentscpesipsec-connectionscross-connectscross-connect-groupsvirtual-circuitsvnicsvnic-attachments
object-family オブジェクト・ストレージ・サービスのリソース・タイプ bucketsobjects
database-family DbaaSサービスのリソース・タイプ db-systemsdb-nodesdb-homesdatabasesbackups
load-balancers ロード・バランサ・サービスのリソース load-balancers
file-family ファイル・ストレージ・サービスのリソース file-systemsmount-targetsexport-sets
dns DNSサービスのリソース dns-zonesdns-recordsdns-traffic
email-family 電子メール配信サービスのリソース approved-senderssuppressions

IAMの動詞とリソース・タイプ権限のマッピングの詳細は、コア・サービスの詳細を参照してください。

IAMのセキュリティ・ポリシーは、条件を使用するときめ細かく設定できます。ポリシーに指定されたアクセス権は、条件文がtrueに評価された場合のみ許可されます。条件は、事前定義済の変数を使用して指定されます。変数では、リクエストに対応するか、操作対象のリソースに対応するかによって、requestまたはtargetというキーワードをそれぞれ使用します。サポートされる事前定義済変数の詳細は、ポリシー・リファレンスを参照してください。

IAMの動的グループを使用して、Oracle Cloud Infrastructure APIにコンピュート・インスタンスがアクセスすることを認可します。インスタンス・プリンシパル機能は、インスタンス上で実行されているアプリケーションがOracle Cloud Infrastructureサービスにプログラムによってアクセスするために使用できます。顧客が作成する動的グループは、メンバーとしてインスタンスを含み、IAMセキュリティ・ポリシーを使用してテナンシ・リソースへのアクセスを認可します。インスタンスによるすべてのアクセスは、顧客が確認できる監査ログに記録されます。

IAMのフェデレーション

  • フェデレーションを使用してコンソールへのログインを管理することをお薦めします。アイデンティティ・フェデレーションはSAML 2.0準拠のアイデンティティ・プロバイダをサポートしており、オンプレミスのユーザーとグループをIAMのユーザーとグループにフェデレートするために使用できます。企業の管理者は、オンプレミスのグループとIAMグループのマッピングの作成に加えて、オンプレミス・アイデンティティ・プロバイダ(IdP)とIAM間のフェデレーション・トラストを設定する必要があります。その後、オンプレミス・ユーザーが、コンソールにシングル・サインオン(SSO)し、所属するIAMグループの認可に基づいてリソースにアクセスできます。コンソールへのフェデレーションの詳細は、アイデンティティ・プロバイダによるフェデレーションを参照してください。フェデレーションは、ユーザー認証(たとえば、マルチファクタ認証)にカスタム・ポリシーを使用する企業にとって特に重要です。フェデレーションでのユーザーとグループの管理の詳細は、アイデンティティ・プロバイダによるフェデレーションを参照してください。
  • フェデレーションを使用するときは、フェデレーション管理者グループを作成して、フェデレーテッドIdP管理者グループにマップすることをお薦めします。フェデレーション管理者グループは、顧客テナンシを管理する管理権限を持ち、フェデレーテッドIdP管理者グループと同じセキュリティ・ポリシーによって制御されます。このシナリオでは、非常時用シナリオ(たとえば、フェデレーションを介してリソースにアクセスできない場合)に対処するために、ローカル・テナンシ管理者ユーザー(つまりデフォルトのテナンシ管理者IAMグループのメンバー)にアクセスできるようにすることが大切です。ただし、高い権限を持つこのローカル・テナンシ管理者ユーザーが不正に使用されないようにする必要があります。テナンシ管理者ユーザーを安全に管理するために次のアプローチをお薦めします。
    1. デフォルトのテナンシ管理者グループに属するローカル・ユーザーを作成します。
    2. ローカル・テナンシ管理者ユーザー用に、非常に複雑なコンソール・パスワードすなわちパスフレーズ(18文字以上、少なくとも1つの小文字、1つの大文字、1つの数字および1つの特殊文字を含む)を作成します。
    3. ローカル・テナンシ管理者ユーザーのパスワードをオンプレミスの場所に安全に保護します(たとえば、パスワードを封筒に入れて封をしオンプレミスの実際の金庫に保管します)。
    4. 保管されたパスワードにアクセスするための、特定の「非常時」シナリオ専用のセキュリティ・ポリシーを作成します。
    5. セキュリティのすり抜けを防ぐため、フェデレーテッドIAM管理者グループが、デフォルト・テナンシ管理者グループのメンバーシップの追加または変更を行わないように、IAMセキュリティ・ポリシーを設定します。
    6. 監査ログをモニターして、デフォルト・テナンシ管理者によるアクセスと管理者グループに対する変更を確認し、認可されていない操作があればアラートを生成します。セキュリティを追加するには、パスワード・ポリシーに基づいて、ログインごとに、または定期的に、ローカル・テナンシ管理者ユーザーのパスワードをローテーションしてください。

様々なIAMコンポーネントの組合せの例は、シナリオ例を参照してください。監査ログを定期的にモニターして、IAMのユーザー、グループ、ポリシー、コンパートメントおよびタグに対する変更を確認します。

セキュリティ・ポリシーの例

一般的なIAMセキュリティ・ポリシーの例は、共通ポリシーを参照してください。この後のすべての例で、ポリシーの対象範囲はテナンシです。ただし、コンパートメント名を指定することによって、テナンシ内の特定のコンパートメントを対象範囲に絞り込むことができます。

最小限の権限を持つサービスレベル管理者を作成

最小限の権限というセキュリティ原則を実装するにために、テナンシのサービスレベル管理者を作成して、管理アクセスの対象範囲をさらに絞り込むことができます。つまり、サービスレベルの管理者は、特定のサービスのリソースしか管理できません。たとえば、ネットワーク管理者は、VCNリソースに対してのみ管理アクセス権(manage)が必要であり、他のリソースには必要ありません。次の例は、ブロック・ストレージ(VolumeAdmins)、VCN (NetworkAdmins)、データベース(DBAdmins)およびオブジェクト・ストレージ(StorageAdmins)の管理者グループを作成する方法を示しています。

Allow group TenancyAdmins to manage all-resources in tenancy
Allow group VolumeAdmins to manage volume-family in tenancy
Allow group NetworkAdmins to manage virtual-network-family in tenancy
Allow group StorageAdmins to manage object-family in tenancy
Allow group DBAdmins to manage database-family in tenancy

セキュリティ・ポリシーを特定のコンパートメントにさらに限定できます。たとえば、企業のHR部門は、コンパートメントHR-compartment内のリソースを管理するためにグループHRAdminsを作成できます。HRNetworkAdminsグループは、HR-compartmentコンパートメント内のVCNリソースのみの管理アクセス権を保持します。

Allow group HRAdmins to manage all-resources in compartment HR-compartment
Allow group HRNetworkAdmins to manage virtual-network-family in compartment HR-compartment

コンプライアンス監査者には、クラウド・リソースを調査し、ポリシー違反を検証するタスクがあります。次のポリシーによって、InternalAuditorsグループはテナンシ内のすべてのリソースの調査(list)が許可されます。

Allow group InternalAuditors to inspect all-resources in tenancy

テナンシのユーザーとグループのみを調査するように監査者を制限する場合は、次のポリシーを使用してグループUserAuditorsを作成できます:

Allow group UserAuditors to inspect users in tenancy
Allow group UserAuditors to inspect groups in tenancy

テナンシ内のVCNファイアウォールのみを検査できる監査者グループを作成する場合は、次のポリシーを使用します:

Allow group FirewallAuditors to inspect security-lists in tenancy

すべてのポリシーの例で、ポリシーにCompartment <name> (<name>はコンパートメント名)を指定することで、ポリシーの対象をコンパートメントに限定できます。

テナンシ管理者グループのメンバーシップの変更権限を制限

グループAdministratorsのメンバーは、テナンシ内のすべてのリソースを管理できます。Administratorsグループのメンバーシップは、そのグループ内のユーザーによって制御されます。通常、テナンシでのユーザーの作成や追加を行うグループがあると便利ですが、そのようなグループがAdministratorsグループのメンバーシップに変更を加えることは制限してください。次の例では、このためにUserAdminsグループを作成します。

Allow group UserAdmins to inspect users in tenancy
Allow group UserAdmins to inspect groups in tenancy
Allow group UserAdmins to use users in tenancy
 where target.group.name!='Administrators'
Allow group UserAdmins to use groups in tenancy
 where target.group.name!='Administrators'

動詞と条件(3番目と4番目のポリシー・ステートメント)を一緒に使用して、UserAdminsがAPI (UpdateUserUpdateGroup)を使用して、Administratorsグループを除くテナンシ内のすべてのグループにユーザーとグループを追加できるようにします。ただし、target.group.name!='Administrators'はlistgetのAPI (ListUsersGetUserListGroupsおよびGetGroup)には関連していないため、これらのAPIは失敗します。そのため、UserAdminsがユーザーおよびグループ・メンバーシップ情報を取得できるようにするには、inspect動詞(1番目と2番目のポリシー・ステートメント)を明示的に追加する必要があります。

セキュリティ・ポリシーの削除または更新の防止

次の例では、PolicyAdminsグループを作成して、テナンシ管理者によって作成されたセキュリティ・ポリシーの作成とリスト表示を行えるようにしますが、削除や更新はできません。

Allow group PolicyAdmins to use policies in tenancy
Allow group PolicyAdmins to manage policies in tenancy
 where request.permission='POLICY_CREATE'

このセキュリティ・ポリシー・ステートメントでは、POLICY_CREATE権限のみが明示的に許可されます。POLICY_DELETEおよびPOLICY_UPDATE権限は許可されません。

管理者によるユーザー資格証明へのアクセスまたは変更の防止

コンプライアンス要件によっては、職務の分離(特にユーザー資格証明の管理業務とテナンシ管理の分離)が求められます。このケースでは、TenancyAdminsCredentialAdminsという2つの管理グループを作成して、TenancyAdminsがユーザー資格証明管理を除くすべてのテナンシ管理業務を実行し、CredentialAdminsがユーザー資格証明を管理するようにします。TenancyAdminsは、ユーザー資格証明のリスト表示、更新または削除を除くすべてのAPIにアクセスできます。CredentialAdminsは、ユーザー資格証明のみを管理できます。

Allow group TenancyAdmins to manage all resources in tenancy
 where all {request.operation!='ListApiKeys',
            request.operation!='ListAuthTokens',
            request.operation!='ListCustomerSecretKeys',
            request.operation!='UploadApiKey',
            request.operation!='DeleteApiKey',
            request.operation!='UpdateAuthToken',
            request.operation!='CreateAuthToken',
            request.operation!='DeleteAuthToken',
            request.operation!='CreateSecretKey',
            request.operation!='UpdateCustomerSecretKey',
            request.operation!='DeleteCustomerSecretKey'}
Allow group CredentialAdmins to manage users in tenancy
 where any {request.operation='ListApiKeys',
            request.operation='ListAuthTokens',
            request.operation='ListCustomerSecretKeys',
            request.operation='UploadApiKey',
            request.operation='DeleteApiKey',
            request.operation='UpdateAuthToken',
            request.operation='CreateAuthToken',
            request.operation='DeleteAuthToken',
            request.operation='CreateSecretKey',
            request.operation='UpdateCustomerSecretKey',
            request.operation='DeleteCustomerSecretKey'}

便利なCLIコマンド

この後のすべての例で、環境変数$Tおよび$Cはそれぞれ、テナンシOCIDとコンパートメントOCIDに設定されます。

テナンシ内のコンパートメントのリスト表示

# list all compartments (OCID, display name, description) in tenancy $T
oci iam compartment list -c $T
# grep above command for important fields
oci iam compartment list -c $T | grep -E "name|description|\"id\""

IAMユーザーのリスト表示

# lists all users (OCID, display name, description) in tenancy $T
oci iam user list -c $T
# grep above command for important fields
oci iam user list -c $T | grep -E "name|description|\"id\"" 

IAMグループのリスト表示

# lists all groups (OCID, display name, description) in tenancy $T.
oci iam group list -c $T
# grep above command for important fields
oci iam group list -c $T | grep -E "name|description|\"id\"" 

グループ内のユーザーのリスト表示

次のコマンドは、グループのユーザー、特に管理権限を持つユーザーをリスト表示する場合に役立ちます。このコマンドには、リスト表示されるユーザーのグループのOCIDが必要です。

# list users in group with OCID <GROUP_OCID>
oci iam group list-users -c $T --group-id <GROUP_OCID>

セキュリティ・ポリシーのリスト表示

# lists all policies (OCID, name, statements) in tenancy $T. Remove pipe to grep to get entire information
oci iam policy list -c $T
# grep above command for important fields
oci iam policy list -c $T | grep -E "name|Allow|\"id\""