Oracle Cloud Infrastructureドキュメント

IAMの保護

セキュリティの推奨事項

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

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

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

IAMテナンシとコンパートメント

  • コンパートメントはIAMに固有のもので、エンタープライズ顧客が単一のアカウントまたはテナンシを持つことによって、その中央のニーズを満たすことができる仕組みを提供します。 この単一の口座またはテナンシは完全な集中管理と可視性を提供すると同時に、構成チーム、プロジェクト、イニシアチブのニーズを満たすために口座またはテナントを細分化することもできます。
  • セキュリティとガバナンスの理由から、ユーザーは必要なリソースにのみアクセスする必要があります。 たとえば、プロジェクトで作業している、またはビジネス・ユニットに属しているエンタープライズ・ユーザーは、プロジェクトまたはビジネス・ユニットに属するリソースにのみアクセスできます。 コンパートメントは、アクセス権限に基づいてテナンシ・リソースをグループ化し、必要に応じてコンパートメントにアクセスするユーザー・グループを認可する有効なメカニズムを提供します。 上記の例では、ビジネス・ユニットに属するすべてのリソースを含むようにコンパートメントを作成し、ビジネス・ユニットのメンバーだけにコンパートメントにアクセスする権限を与えます。 同様に、コンパートメントへのグループ・アクセスは、もはや必要としないときに取り消すことができます。
  • コンパートメントを作成してリソースを割り当てるときは、次の点に注意してください:
    • すべてのリソースはコンパートメントに属している必要があります。
    • リソースは、作成後に別のコンパートメントに再度割り当てることができます。 「コンパートメントの管理」も参照してください。
    • コンパートメントは、作成後に削除できます。 「コンパートメントの管理」も参照してください。
  • リソース・タグは、複数のコンパートメントに分散されたリソースを論理的に集約する手段を提供します。 たとえば、テナンシ・リソースには、その用途に応じて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つの番号が含まれています
  • 90日以内にIAMパスワードとAPIキーを定期的にローテーションします。 セキュリティ・エンジニア・リングのベスト・プラクティスに加えて、これはコンプライアンス要件でもあります。 たとえば、PCI-DSSセクション3.6.4では、キー管理手順に、使用されている各キータイプに対して定義された暗号化期間が含まれていることを検証し、定義された暗号化期間の最後にキー変更のプロセスを定義すると述べています。
  • 機密性の高いIAM資格証明を、幅広いオーディエンスからアクセス可能なソフトウェアまたは文書で直接ハードコードしないでください。 例としては、GitHubにアップロードされたコード、プレゼンテーション、インターネット上で入手できる文書などがあります。 パブリック・サイトで不注意に開示された資格証明を使用して、クラウド・アカウントに違反するハッカーの公表されたケースが知られています。 ソフトウェア・アプリケーションがOracle Cloud Infrastructureリソースにアクセスする必要がある場合は、Instance Principalを使用することをお薦めします。 Instance Principalを使用できない場合は、ユーザー環境変数を使用して資格証明を格納し、Oracle Cloud Infrastructure SDKまたはCLIで使用するAPIキーを使用してローカルに格納された資格証明ファイルを使用することをお勧めします。
  • 複数のユーザー間でIAM資格証明を共有しないでください。
  • Oracle Identity Cloud Serviceを使用してコンソール・ログインをフェデレートすることにより、顧客はIAMユーザー、特に管理者に複数のファクタを使用できます。

APIキーを回転させるときは、古いキーを無効にする前に回転キーが期待通りに機能することを確認します。 IAM APIキーの生成とアップロードについては、「必要なキーとOCID」を参照してください。 APIキーを回転する際の高度なステップは次のとおりです:

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

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は最小特権を許可し、管理は最大限許可します。 4つの動詞は、次の表の昇順に表示されます。

IAMポリシー動詞
動詞 アクセス・タイプ ユーザーの例
検査 メタデータのみを表示する必要があります。 これは、通常、リソースをリストする機能のみをもたらします 第三者審査員
read さらに、リソースとユーザーのメタデータを読み取る機能を備えています。 これは、ほとんどのユーザーが作業を完了するために必要な許可です。 内部監査人
use 読み取りとリソース操作の機能(リソース・タイプによってアクションが異なります)。 リソースの作成または削除機能を除外 通常のユーザー(ソフトウェア開発者、システム・エンジニア、開発者マネージャなど)、テナンシ・リソースの設定と構成、それらのアプリケーションの実行
manage すべてのリソースに対するすべての権限 管理者、エグゼクティブ(ブレーク・グラス・シナリオ用)

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

IAMリソース・ファミリ、説明、およびリソース・タイプ
リソース・タイプ・ファミリ説明リソース・タイプ
all-resourcesすべてのリソース・タイプ 
設計上の名前なしIAMサービスのリソース・タイプcompartments, users, groups, dynamic-groups, policies, identity-providers, tenancy tag-namespaces, tag-definitions
instance-familyコンピューティング・サービスのリソース・タイプconsole-histories, instance-console-connection, instance-images, instances, volume-attachments
volume-familyブロック・ストレージ・サービスのリソース・タイプvolumes, volume-attachments, volume-backups
virtual-network-family仮想ネットワーキング・サービスにおけるリソース・タイプvcns, subnets, route-tables, security-lists, dhcp-options, private-ips, public-ips, internet-gateways, local-peering-gatewaysdrgs, deg-attachments, cpes, ipsec-connections, cross-connects, cross-connect-groups, virtual-circuits, vnics, vnic-attachments
object-familyオブジェクト・ストレージ・サービスのリソース・タイプbuckets, objects
database-familyDbaaSサービスのリソース・タイプdb-systems, db-nodes, db-homes, databases, backups
load-balancersLoad Balancerサービスのリソースload-balancers
file-familyファイル・ストレージ・サービスのリソースfile-systems, mount-targets, export-sets
dnsDNSサービスのリソースdns-zones, dns-records, dns-traffic
email-family電子メール配信サービスのリソースapproved-senders, suppressions

IAM verbとリソース・タイプのアクセス許可マッピングの詳細については、「コア・サービスの詳細」を参照してください。

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

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

IAMフェデレーション

  • フェデレーションを使用してコンソールへのログインを管理することをお薦めします。 IDフェデレーションは、SAML 2.0準拠のアイデンティティ・プロバイダをサポートし、オンプレミス・ユーザーおよびグループをIAMユーザーおよびグループにフェデレートするために使用できます。 エンタープライズ管理者は、オンプレミス・グループとIAMグループ間のマッピングの作成に加えて、オンプレミス・アイデンティティ・プロバイダ(IdP)とIAM間のフェデレーション・トラストを設定する必要があります。 次に、オンプレミスのユーザーはコンソールにシングル・サインオン(SSO)を行い、所属するIAMグループの承認に基づいてリソースにアクセスできます。 コンソールへのフェデレーションの詳細は、「アイデンティティ・プロバイダのフェデレート」を参照してください。 フェデレーションは、ユーザー認証(たとえば、複数要素認証)のカスタム・ポリシーを使用する企業にとって特に重要です。 フェデレーション下のユーザーおよびグループの管理の詳細は、「アイデンティティ・プロバイダのフェデレート」を参照してください。
  • フェデレーションを使用する場合は、フェデレートされたIdP管理者グループにマップするフェデレーション管理者グループを作成することをお薦めします。 フェデレーション管理者グループには、フェデレートされたIdP管理者グループと同じセキュリティ・ポリシーによって管理されながら、顧客テナンシを管理するための管理者権限が与えられます。 このシナリオでは、ブレーク・グラス・タイプのシナリオを処理するために、ローカルテナンシ管理者ユーザー(つまり、デフォルトのテナンシ管理者IAMグループのメンバー)にアクセスすることをお勧めします(フェデレーションを通じてリソースにアクセスできないなど) )。 ただし、この高度に権限のあるローカルテナンシ管理者ユーザーの不正使用を防ぐ必要があります。 Oracleでは、テナンシ管理者ユーザーを安全に管理するために、次の方法を推奨します:
    1. デフォルトのテナンシ管理者グループに属するローカル・ユーザーを作成します。
    2. ローカルのテナンシ管理者ユーザー用に、非常に複雑なコンソール・パスワードまたはパスフレーズ(18文字以上、小文字、大文字、数字、特殊文字をそれぞれ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部門は、グループHRAdminsを作成して、そのコンパートメント内のリソースHR-compartmentを管理できます。 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'

UserAdminsAdministratorsグループを除くテナンシ内のすべてのグループにAPI (UpdateUserUpdateGroup)を使用してユーザーおよびグループを追加できるように、条件付きの動詞(第3および第4のポリシー・ステートメント)を使用できます。 ただし、target.group.name!='Administrators 'はlistおよびget API (ListUsersGetUserListGroups、およびGetGroup)には関係しないため、これらのAPIは失敗します。 したがって、UserAdminsがユーザーおよびグループのメンバーシップ情報を取得できるように、inspect verb (第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を除くすべての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\""