OCI技術資料 : IDおよびアクセス管理 (IAM) 詳細

Oracle Cloud Infrastructure (OCI) の技術説明資料、IDおよびアクセス管理 (IAM) の詳細編 (Level 200) です。

下記の内容について解説しています。
- インスタンス・プリンシパルと動的グループ
- 認証の強化
- 高度なポリシーの記述
- フェデレーションの詳細
- コンパートメント階層とポリシーの継承
- コンパートメントの移動
- IAMの設計リファレンス

更新履歴
2024/1/24 最新情報を反映
2024/6/19 クロステナンシのリストを追加

Transcript

1. IDおよびアクセス管理 詳細 Identity and Access Management Level 200 Oracle Cloud Infrastructure 技術資料 2024年6月
2. OCI – Oracle Cloud Infrastructure OCI IAM または IAM – Identity and Access Management IDCS – Identity Cloud Service IDM または ID管理 – ユーザー、グループ、認証方法などアイデンティティ(ID)情報を管理する機能 Authentication、AuthN – 認証、ユーザーなどの本人確認を行ってサインインを許可する仕組み Authorization、Auth0 – 認可、リソースへのアクセス可否を制御する仕組み ACL – Access Control List、認可を行うためのアクセス許可情報を格納したもの 用語 Copyright © 2024 Oracle and/or its affiliates. 2
3. この資料は、Oracle Cloud Infrastructure (以下OCI) におけるIdentity and Access Management (以下 IAM) の説明資料です。 内容は予告なく変更される可能性があるため、最新の情報や詳細については、下記のサイトをご覧くだ さい。 • OCIトレーニング • https : //cloud.oracle.com/iaas/training • OCIドキュメント • https : //docs.cloud.oracle.com/iaas/Content/home.htm はじめに Copyright © 2024 Oracle and/or its affiliates. 3
4. いままで アイデンティティ・ドメインのないIAM + IDCS (Identity Cloud Service) これから アイデンティティ・ドメインのあるIAM はじめに – OCIのID管理/認証は切り替わりの過渡期 (2021/11/9~) OCI IAM Default アイデンティ ティ・ドメイン 追加 アイデンティ ティ・ドメイン Policy 認可 ID 認証 Policy 認可 ID 認証 OCIリソース 外部 アプリ OCI IAM Policy 認可 ID 認証 OCIリソース IDCS SaaS インスタンス インスタンス SaaS インスタンス 外部 アプリ ID 認証 ID 認証 ID 認証 Federation 2022年3月現在 : 新規作成テナンシは切り替わり済、既存テナンシは将来切り替わり予定 Copyright © 2024 Oracle and/or its affiliates. 4
5. アイデンティティ・ドメインのないIAM + IDCS ▶︎ アイデンティティ・ドメインのあるIAM IAM単独管理 or IDCSで管理してIAM連携 (Federated User)の2種類を使い分け ユーザー IAMのみで管理 (アイデンティティドメイン内で管理) IAM単独管理 or IDCSで管理してIAM連携(グループ マッピング)の2種類を使い分け グループ IAMのみで管理 (アイデンティティドメイン内で管理) IAMとIDCSをユーザーによって使い分け サインイン IAMのみで実施 できない (IDCS側は複数体系持てるがIAM側が複数持てない) 複数ID体系 できる (追加アイデンティティドメインで実施) できない ID管理業務の委譲 できる (追加アイデンティティドメインで実施) 基本的にIDCSで実施 (一部の二段階認証を除く) 高度な認証 IAMで実施 (IDCSの機能は全てIAMに移植) IDCSでのみ実施できる 外部アプリの認証 IAMで実施できる IAMのポリシーで制御 認可・アクセス制御 基本的に変更なし (アイデンティティ・ドメインを指定できるように文法拡張) 切り替わりでOCIのID管理はどう変わる? Copyright © 2024 Oracle and/or its affiliates. 5
6. この資料は、OCIのサービスを使う上で必要な OCI IAM の機能を中心に解説しています • ユーザー、グループ、ポリシー、コンパートメント、動的グループ、タグ など IDCSおよびアイデンティティ・ドメインに関連する機能については、それぞれ別資料で解説しています • Oracle Identity Cloud Service 機能概要 https://speakerdeck.com/oracle4engineer/oracle-identity-cloud-service-ji-neng-gai-yao • OCI IAMとIDCSの違いとIDCSを利用するメリット https://speakerdeck.com/oracle4engineer/oci-iamtoidcsfalsewei-itoidcswoli-yong-surumerituto • OCI新認証基盤について知ろう https://speakerdeck.com/oracle4engineer/overview-oci-iam-identity-domains • 2021/11に導入されたOCI IAM Identity Domainsについての解説 • Default以外のアイデンティティ・ドメインそのものの管理 • 外部アプリケーションの認証 • 新しいOCI IAMに追加された高度な認証や管理機能 この資料のカバー範囲 Copyright © 2024 Oracle and/or its affiliates. 6
7. 概要 (Level 100) • プリンシパルと認証 • 認可とポリシー • コンパートメント • フェデレーション • タグ付け 詳細 (Level 200) • インスタンス・プリンシパルとダイナミッ ク・グループ • 高度なIAM認証 • 高度なポリシーの記述 • フェデレーションの詳細 • コンパートメント階層とポリシーの継承 • コンパートメントの移動 • IAMの設計リファレンス OCI IAMトレーニングの全体像 Copyright © 2024 Oracle and/or its affiliates. 7
8. Copyright © 2024 Oracle and/or its affiliates. 8 インスタンス・プリンシパルと 動的グループ Instance Principals and Dynamic Groups
9. OCIにおける プリンシパル とは? • OCIリソースに対するCRUD操作を実行する行動主体 • IAMユーザー、リソース・プリンシパル、サービス・プリンシパルの3種 (A) ユーザー (Users) • 個人やアプリケーションを表し、コンソール操作とAPIコールに利用 • グループへの所属を通じてリソースへのアクセス権が付与される (B) リソース(インスタンス)・プリンシパル (Resource Principals)* • OCIリソース (とその上のAPIコールクライアント) 自体にアクセス権を付 与 • 動的グループ(リソースをグループ化するエンティティ)とともに利用 (C) サービス・プリンシパル (Service Principals) • OCIサービスに対してユーザー所有リソースへのアクセス権を付与 • ユーザーによるサービス・プリンシパルの登録は不可、予め登録済み *リソース(インスタンス)・プリンシパルの詳細はL200の資料を参照 プリンシパル (Principals) Copyright © 2024 Oracle and/or its affiliates. 9 アクセス対象の OCIリソース ユーザー リソー ス・プリ ンシパル グループ サービ ス・プリ ンシパル 認証 & 認可 動的グループ
10. インスタンス・プリンシパル (Instance Principals) 概要 インスタンス・プリンシパル を使用すると、ユーザーや資格証明(API署名鍵など)をインスタンスに配置 しなくてもインスタンスで動くアプリケーションからAPIをコールできるようになる インスタンス・プリンシパルがない場合… • APIキーをすべてのインスタンスに格納する必要がある • APIキーのローテーションの際にインスタンスの鍵も変更する必要がある • (通常はAPIキーは共通にするため)インスタンスレベルのアクセス監査ができない インスタンス・プリンシパルを使用すると… • インスタンスに対して独自のアクセス許可を付与(新しいプリンシパルとして追加)するため不要な APIキーを発行する必要がない • ある基準を満たすインスタンスを動的にグループ化して権限を付与できる(動的グループ) • 監査ログにAPIをコールしたインスタンスのIDが格納されるため、インスタンス単位で監査ができる Copyright © 2024 Oracle and/or its affiliates. 10
11. 認証、認可はインスタンスレベルで行われる • ユーザは証明書管理をする必要なし ポリシーは 動的グループ を使用して付与される • 動的グループを使用すると、ユーザーが所属する通常のグループと 同様にインスタンスをグループ化できる • ポリシーは動的グループレベルで設定されます • 動的グループは、一致ルールと呼ばれる一連の基準によって決定さ れ、ルールに適合するリソースが動的グループのメンバーになる ポリシーの記述例 Allow dynamic-group <group-name> to manage XXX in tenancy インスタンス・プリンシパルを使用した認証 アクセス対象の OCIリソース IAM ユーザー インスタン ス・プリン シパル 認証 & 認可 グループ 動的グループ Copyright © 2024 Oracle and/or its affiliates. 11
12. ステップ1 - 動的グループ (Dynamic Group) の作成 インスタンス・プリンシパルの利用手順 12 この例では特定のコンパートメントの中の すべてのインスタンスがこの動的グループ に自動的に所属する マッチング・ルールに一致するインスタンスが動的グループに追加されるよう設定 • ルールに条件として使用できるパラメーター : • コンパートメントOCID • インスタンスOCID • タグ名前空間とタグ・キーの組み合わせ • タグ・名前空間とタグ・キーとタグ値の組み合わせ • 特定のインスタンスが動的グループから除外するように設定することも可能 Copyright © 2024 Oracle and/or its affiliates.
13. ステップ2 - 動的グループに対するポリシーを作成 インスタンス・プリンシパルの利用手順 13 この例では先ほど作成した FrontEnd という動的グ ループ(に所属するインスタンス)に対し、バケットと オブジェクトの管理権限を付与している Copyright © 2024 Oracle and/or its affiliates.
14. ステップ3 – インスタンスにコードをデプロイ インスタンス・プリンシパルの利用手順 Copyright © 2024 Oracle and/or its affiliates. 14 [opc@webserver1 .oci]$ oci os ns get ERROR: The config file at ~/.oci/config is invalid: +Config Errors-------+--------------------------------------------------------+ | Key | Error | Hint | +----------+---------+--------------------------------------------------------+ | key_file | missing | the full path and filename of the private PEM key file | +----------+---------+--------------------------------------------------------+ [opc@webserver1 .oci]$ cat config [DEFAULT] user=ocid1.user.oc1..aaaaaaaag3635pdkcopjvcvljf7kmo7besxqzeqiry2wzawa4zqk2xkx4z7q fingerprint=93:4f:c0:c3:26:3b:06:9f:c8:17:60:78:23:e1:1c:90 # key_file=/home/opc/.oci/oci_api_key.pem API署名鍵をコメントアウト tenancy=ocid1.tenancy.oc1..aaaaaaaaxy6bh46cdnlfpaibasc6dotowv32hc2sbj4ph3ocxtfxhhva2hna region=us-ashburn-1 [opc@webserver1 .oci]$ oci os ns get --auth instance_principal { "data": "intoraclerohit" } 上記はOCI CLI の例だが、他にSDK(Java, Python, Goなど)やAPIを直接コールするプログラムからもインスタン ス・プリンシパルを利用可能  通常のアクセスでは認証エラー  認証にインスタンス・プリンシパルを使用するように するとAPIコールに成功
15. バックグラウンドでの動作メカニズム(1/2) OCIメタデータ・サービス各インスタンスに発行する X.509 PKI 証明書を使って認証 • 証明書はOCI内部の認証局(CA)によってサイン • 証明書にはインスタンスの固有情報(インスタンスID、コンパートメントID等)を含む OCI SDK/CLI がインスタンス・プリンシパルを用いてアクセスする際の動作 1. SDK/CLI がインスタンス・メタデータ・サービス (http://169.254.169.254/opc/v1/identity/cert.pem)をコールして X.509 証明書を取得 2. SDK/CLI は取得した証明書を用いて OCI の認証サービスをコール 3. OCI の認証サービスは提示された証明書の発行元をチェックしてトークンを発行 4. SDK/CLI は取得したトークンを用いて OCI の API をコール 5. コール時にはインスタンスに紐付けられたポリシーに一致する認可が付与 インスタンス・プリンシパル Copyright © 2024 Oracle and/or its affiliates. 15
16. バックグラウンドでの動作メカニズム(2/2) OCIネットワークのPKIエージェントが定期的にPKI証明書をリフレッシュし、そのたびにSDK/CLIは証明 書を再取得し再度認証サービスからトークンを取得 X.509 証明書は curl コマンドなどで確認できる http://169.254.169.254/opc/v1/identity/cert.pem インスタンス・プリンシパル Copyright © 2024 Oracle and/or its affiliates. 16 [opc@webserver1 .oci]$ curl http://169.254.169.254/opc/v1/identity/cert.pem -----BEGIN CERTIFICATE----- MIIIPjCCBiagAwIBAgIQesV+WyeYgLqUxb4vSgrL/jANBgkqhkiG9w0BAQsFADCB qTFzMHEGA1UECxNqb3BjLWRldmljZTo1NDo1Yjo4NTpiOTowMjo5Yjo4YTo4MDpl YTo1MjoxNzo1MjozYjo1ZjowZjpmMzo1MTpkNjo1YzoxZjpmYTozYTo1MTo4OTow ZDpjMTowNTo0MjphOTowYzplMTo4YjEyMDAGA1UEAxMpUEtJU1ZDIElkZW50aXR5 IEludGVybWVkaWF0ZSB1cy1hc2hidXJuLTEwHhcNMTgwNjE1MTc0MjU1WhcNMTgw NjE1MTg0MjU1WjCCAbQxggFSMBwGA1UECxMVb3BjLWNlcnR0eXBlOmluc3RhbmNl MGcGA1UECxNgb3BjLWluc3RhbmNlOm9jaWQxLmluc3RhbmNlLm9jMS5pYWQuYWJ1 d2NsanRrYWMyMjZzbDY1N3hsbHIzNWszaGozYWJra3I3dm9sd3BndWd6c3Nkdjd2
17. Copyright © 2024 Oracle and/or its affiliates. 18 認証の強化 Reinforced Authentication
18. IAMサービスは下記いずれかの 資格証明(Credentials) でプリンシパルを 認証 する 認証 (Authentication) Copyright © 2024 Oracle and/or its affiliates. 19 API署名鍵 認証トークン ユーザ名、パスワード • Webコンソールへのログインに使用 APIキー (API Signing Key) • OCIネイティブのAPI、SDK、CLIを使用する場合に使 用 • PEM形式のRSA鍵ペア (最低2048ビット) 認証トークン (Auth Token) • Swift互換APIなどトークンで認証するタイプのAPIで 使用 顧客秘密キー (Customer Secret Keys) • S3互換APIなど、通常のAPIキーとは異なる鍵を利用 するAPIで使用 • 旧称 : Amazon S3互換APIキー
19. 多要素認証（MFA）は、ユーザーのIDを確認するために複数の要素を使用する必要がある認証方法 例えば、パスワード (What You Know) の他に、デバイス(What You Have) を認証要素として利用する ようなケース 多要素認証 (MFA) とは Copyright © 2024 Oracle and/or its affiliates. 20
20. Step 1 Step 2 Step 3 OCI IAM での 多要素認証の有効化方法 Copyright © 2024 Oracle and/or its affiliates. 21
21. CLIでのトークンベースの認証 Copyright © 2024 Oracle and/or its affiliates. 23 oci session authenticate (1) CLIセッション開始コマンドを実行 (2) 起動したブラウザで認証情報を入力 (3) CLIセッションが開始 認証情報は .config ファイルに保存される CLI/SDKでは、通常のAPIキーによる認証に加え てトークンによる認証も利用可能 • 認証時にAPIキーが不要 • 代わりに認証トークンの取得のためにWebブ ラウザによる資格証明の提示が必要 • →ブラウザがないCLI環境では、ブラウザがあるコ ンピューターで取得した認証トークン(.config)を インポートしてくる必要がある • 認証トークンの有効期間(TTL)は1時間 CLIコマンドにより最長24時間まで延長可能 • SCIM対応ではないアイデンティティ・プロバ イダ(Azure ADなど)からフェデレートされた ユーザー(APIキーが設定できない)もCLIやSDK を使用できる oci session refresh --profile <profile_name>
22. アクセス元のIPアドレスによってリソースへのアクセス制御を行う ネットワーク・ソースとは、 IPアドレスのセットやVCNを定義したリソース • パブリックIPアドレス、もしくはテナンシ内のVCNからのIPアドレスを設定可能 作成したネットワーク・ソースをポリシー内でwhere条件に指定し、元IPアドレスに基づいたアクセス制御が可能 • コンソールへのログインを特定のIPアドレス範囲からのみに制限（テナンシーレベルでの設定） • IAMポリシーで各リソースへのアクセスを特定のIPアドレス範囲からに制限（各IAMポリシーでの設定） • 例：オブジェクト・ストレージへのアクセスを特定のIPアドレス範囲（VCN内IPの特定IPなど）からのみに制限 ネットワーク・ソースによるアクセス制御 Copyright © 2024 Oracle and/or its affiliates. 24 OCI リージョン コンピュート インスタンス allow group groupA to manage object-family in tenancy where request.networkSource.name=‘VCNCIDR' オブジェクト ストレージ VCN A 10.0.0.0/16 サービス ゲートウェイ VCN Aの 10.0.0.0/24 からのみ許可 192.0.2.0/24 からのみ許可 サブネット 10.0.0.0/24 そのほかのIPアドレス 192.0.2.2
23. Copyright © 2024 Oracle and/or its affiliates. 25 高度なポリシーの記述 Advanced Policies
24. Allow <subject> to <verb> <resource-type> in <location> [where <condition>] ポリシー(Policies)のシンタックス その1 Copyright © 2024 Oracle and/or its affiliates. 26 シンタックス 説明 例文 group <グループ名> グループを名称で指定 group A-Admin group id <グループの OCID> グループをOCIDで指定 group id ocid1.group.oc1..aaaaaaaaqjihfh vxmum...awuc7i5xwe6s7qmnsbc6a any-user すべてのユーザーを指定 any-user https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policysyntax.htm
25. Allow <subject> to <verb> <resource-type> in <location> [where <condition>] ポリシー(Policies)のシンタックス その2 Copyright © 2024 Oracle and/or its affiliates. 27 Verb(動 詞) アクセスのタイプ 対象者 Inspect (検査) ユーザー指定のメタデータ以外の読 み取り専用アクセス 外部監査人 Read (参照) 読み取り専用アクセスとユーザー指 定のメタデータを取得する 内部監査人 Use (利用) 読み取りと既存のリソースを処理す る機能（アクションはリソースタイ プによって異るが通常作成や削除は 不可） 日常のユー ザー Manage (管理) リソースのすべてのアクセス許可が 含まれます 管理者 集合リソースタイプ 個別リソースタイプ all-resources database-family db-systems, db-nodes, db-homes, databases instance-family instances, instance-images, volume- attachments, console-histories object-family buckets, objects virtual-network-family vcn, subnet, route-table, more volume-family Volumes, volume-attachments, volume-backups https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policysyntax.htm
26. Allow <subject> to <verb> <resource-type> in <location> [where <condition>] ポリシー(Policies)のシンタックス その3 Copyright © 2024 Oracle and/or its affiliates. 28 シンタックス 説明 例文 tenancy テナンシ全体を指定 in tenancy compartment <コンパートメント名> コンパートメントを名称で指定 in compartment Project-A Compartment id <コンパートメントの OCID> コンパートメントのOCIDを指 定 in compartment id ocid1.compartment.oc1..aaaaaaaayzfq...4 fmameqh7lcdlihrvur7xq https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policysyntax.htm
27. Allow <subject> to <verb> <resource-type> in <location> [where <condition>] ポリシー(Policies)のシンタックス その4 Copyright © 2024 Oracle and/or its affiliates. 29 シンタックス 説明 例文 <変数> = <値> 一致条件 where target.group.name = /A-Users-*/ <変数> != <値> 不一致条件 Where target.group.name != ‘Administrators’ all {<condition>, <condition>, …} すべての条件を満たす(AND条件) where all {target.group.name=/A- */,target.group.name!='A-Admins'} any {<condition>, <condition>, …} 一部の条件を満たす(OR条件) where any {target.group.name=/A- Admins/,target.group.name=‘A-Users'} Verb と resource-type の取りうる組み合わせのパターンの詳細については以下を参照 https://docs.oracle.com/ja-jp/iaas/Content/Identity/Reference/policyreference.htm
28. Allow <subject> to <verb> <resource-type> in <location> [where <condition>] ポリシー(Policies)のシンタックス その4(続き) Copyright © 2024 Oracle and/or its affiliates. 30 主な変数 説明 request.operation 要求されているAPI操作名 request.permission 要求されているパーミッション request.user.id 要求したユーザのOCID request.groups.id 要求したユーザが所属するグ ループID target.compartment.id コンパートメントのID target.compartment.name target.compartment.idで指定さ れたコンパートメント request.region リクエストが作成されたリー ジョンのキー（phx、iadなど） request.ad リクエストが作成された可用性 ドメインの名前 2つのリクエストのタイプ • request: リクエスト自体に関連 • target: requestで処理されているリソースに関連 変数名はrequestまたはtargetの後のピリオドに詳細 が続く Conditionsを使用したポリシーの例 • Allow group Phoenix-Admins to manage all-resources in tenancy where request.region='phx'
29. ポリシーを 動詞(Verb) を使って記述すると、内 部的には事前定義された パーミッション (Permissions) の集合体として定義される • パーミッションは、リソースに対する操作権 限として 定義されている原子単位 • Inspect < Read < Use < Manage とアクセス レベルが上がるにつれて、パーミッションが 累積されていく • 全てのAPI操作に対して対応する必要なパー ミッションが定義されている ‐ 例 : ListVolumes や GetVolumes をコールす るには、VOLUME_INSPECTパーミッション が必要 動詞 (Verbs) とパーミッション (Permissions) Copyright © 2024 Oracle and/or its affiliates. 31 動詞 (Verb) パーミッション (Permssions) API操作 volume- family Inspect Volume- Inspect Volume- Inspect Read + Read Use Manage Volume- Update Volume- Write Use + Volume- Create Volume- Delete ListVolumes GetVolumes CreateVolume DeleteVolume リソース・ タイプ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・ ・
30. パーミッションやAPI操作を使用してアクセス制御をする方法 通常ポリシーを作成する時はパーミッションやAPI操作は内部的に指定されるためユーザは使用しないが、 条件句で明示的に指定して操作を制限することが可能 設定例 : ユーザにVCN削除以外のVCN管理権限を与えたい場合 • allow group TrainingGroup to manage virtual-network-family in compartment training where request.permission != 'VCN_DELETE' Copyright © 2024 Oracle and/or its affiliates. 32
31. タグを利用したアクセス制御 Copyright © 2024 Oracle and/or its affiliates. 33 WHERE句による権限の絞り込みにはタグを利用可能 • パターン1 : プリンシパルを制限する場合 • allow any-user to manage instances in compartment HR where request.principal.group.tag.Operations.Project = 'Prod' → OperationsネームスペースのProjectタグにProdが設定されているグループの所属ユーザーのみが操作可能 • パターン2 : 対象リソースを制限する場合 • allow group GroupA to manage all-resources in compartment HR where target.resource.tag.Operations.Project = 'Prod' → OperationsネームスペースのProjectタグにProdが設定されているリソースの操作のみが可能 利用上の注意 → 詳細はドキュメントを参照 • 操作対象リソースのタグを判別するために、リソースのList権限が必ず別に必要 →タグで絞らない別ステートメントで(INSPECTなどで)LISTパーミッションを付与 • タグで絞り込んだ権限ではMANAGE権限であっても新規リソースは作成できない →必要ならタグで絞り込まない別ステートメントでCREATEパーミッションを付与 • ポリシー内の制限に抵触する文字はタグネームスペースやタグキー定義で利用できない
32. ユースケース 例文 ネットワーク管理者にクラウドネットワーク 管理権限を付与 • Allow group NetworkAdmins to manage virtual-network-family in tenancy ユーザーにインスタンスの作成権限を付与 • Allow group InstanceLaunchers to manage instance-family in compartment ABC • Allow group InstanceLaunchers to use volume-family in compartment ABC • Allow group InstanceLaunchers to use virtual-network-family in compartment XYZ バックアップ管理者にボリュームのバック アップを管理できる権限のみを付与 • Allow group VolumeBackupAdmins to use volumes in tenancy • Allow group VolumeBackupAdmins to manage volume-backups in tenancy • Allow group VolumeBackupAdmins to inspect volume-attachments in tenancy • Allow group VolumeBackupAdmins to inspect instances in tenancy ユーザーにオブジェクト・ストレージ・バ ケットにオブジェクトの書込権限を付与 • Allow group ObjectWriters to read buckets in compartment ABC • Allow group ObjectWriters to manage objects in compartment ABC where any {request.permission='OBJECT_CREATE', request.permission='OBJECT_INSPECT'} コンパートメント管理者にコンパートメント の管理権限を付与 • Allow group A-Admins to manage all-resources in compartment Project-A 管理者に特定リージョンのアクセス権を付与 • Allow group Phoenix-Admins to manage all-resources in tenancy where request.region='phx' 監査人にリソースの監査権限を付与 • Allow group Auditors to inspect all-resources in tenancy • Allow group Auditors to read instances in tenancy • Allow group Auditors to read audit-events in tenancy ユースケース別のポリシー記述サンプル 他にも多数の記述例はこちら : https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policysyntax.htm Copyright © 2024 Oracle and/or its affiliates. 34
33. OCIのサービスがプリンシパルとなるもの <allow service XXX to …> • 例1 : Oracle Container Engine for Kubernetes(OKE)がリソースを作成できるよ うに権限を付与 allow SERVICE OKE to manage all- resources in compartment A • 例2 : 東京リージョンのObject Storageがリー ジョン間レプリケーションのための操作がで きるように権限を付与 allow SERVICE OBJECTSTORAGE-AP-TOKYO- 1 to manage object-family in compartment A 他のテナンシへのアクセス権を扱うもの <endorse … in tenancy XXX> • 例1 : クロス・テナンシ・ピアリングの作成に 必要な権限を付与 ENDORSE group <group> to manage local-peering-to IN TENANCY <tenancy> • 例2 : コスト&使用状況レポートのデータが格 納されているOCIの管理テナンシへのアクセ ス権限を付与 ENDORSE group <group> to read objects IN TENANCY USAGE-REPORT その他の少し変わったポリシー句 Copyright © 2024 Oracle and/or its affiliates. 35 いずれの場合も、マニュアルのポリシーの作成が必要なシーンの箇所に個別の指示があるので、それ に従って作成してください
34. Copyright © 2024 Oracle and/or its affiliates. 36 フェデレーションの詳細 Identity Federation
35. OCIを使用するにあたって、主に使用する認証およびID管理サービスは下記の2つ A) Oracle Identity Cloud Service • Oracle Cloudの全てのサービスで使用される統合的な認証・ID管理サービス B) OCI Identity and Access Management (IAM) • Oracle Cloud Infrastructure 単独の環境でネイティブに使用される認証・ID管理サービス OCIの認証・ID管理機能の位置付け Copyright © 2024 Oracle and/or its affiliates. 37 Oracle Identity Cloud Service OCI Identity and Access Management Oracle PaaS サービス群 Oracle SaaS サービス群
36. IDCS機能を利用して、IPアドレスによるWhitelisting、Backlistingでのアクセス制御の利用が可能 IDCSを使ったOCI認証の強化 – IPホワイトリスティング Copyright © 2024 Oracle and/or its affiliates. 38 ＜ネットワーク境界 (Network Perimeter)＞ 10.11.12.18/24 ＜サインオン・ポリシー＞ 条件： 1. 認証に利用されているIDプロバ イダ 2. 所属グループ 3. ネットワーク境界 アクション： Allow/Deny ＜グループ＞ OCI_Administrator ＜ユーザ＞ Sato Suzuki サインオン・ポリシーにネットワーク境界を設定し、アクションとして Alow/Denyを設定する事により、IDCSのアカ ウントを利用して サインオンするユーザに対して、IP ホワイトリスティング、IP ブラックリスティング の機能を提供 ＜留意事項＞ • ネットワーク境界の機能は、IDCSの機能であり、OCI側で作成したユーザでは利用できません • 他要素認証など、利用する機能によっては、別途IDCSのサービスを購入する必要があります
37. IDCSを使ったOCI認証の強化 – IPホワイトリスティング Copyright © 2024 Oracle and/or its affiliates. 39 アプリケーション単位で次の属性 でアクセスの許可や拒否、再認証 や二要素認証の要求をポリシーと して指定 • 使用したIdP • ユーザー名 • 所属グループ • IPアドレス 「サインオン・ポリシー」で アクセスを許可/拒否するルールを 複数設定して、順番に実行 イントラネットからの アクセスはID/PWのみ許可 インターネットからのアクセスには 二要素認証や再認証を要求 イントラネットの IPの範囲指定
38. IDCSを使ったOCI認証の強化 – 多要素認証 Copyright © 2024 Oracle and/or its affiliates. 40 アプリケーションで の通知への応答 SMSによる ワンタイムパス ワード アプリケーション でのワンタイムパ スワード 秘密の質問 メールによるワンタ イムパスワード パスワード ID ログイン 二要素認証 IDとパスワー ドによるログ イン インターネット 社内 ネットワーク クラウド・ サービス IPホワイト・リストによる二要素認証のスキップ OCIコンソール
39. • 管理画面で有効化すれば設定が完了 • モバイル・アプリケーションの設定は、ユーザーがQRコードを読み込むだけ IDCSを使ったOCI認証の強化 – 多要素認証 Copyright © 2024 Oracle and/or its affiliates. 41 利用する 方式を選択 同じブラウザであれば 一定期間第2認証をスキップ
40. Copyright © 2024 Oracle and/or its affiliates. 44 コンパートメント階層とポリシーの継承 Policy Inheritance and Attachment for Compartments
41. Oracle Cloud Infrastructure リージョン - Phoenix リージョン - Ashburn テナンシ (Tenancy) = ルート・コンパートメント (Root Compartment) コンパートメントA • 最上位(root)のコンパートメ ント = テナンシ(tenancy) • コンパートメントは階層化 できる(最大6層) • 上位コンパートメントに与 えられたアクセス権限は下 位コンパートメントに継承 される コンパートメントによる階層型のアクセス権管理 Copyright © 2024 Oracle and/or its affiliates. 45 コンパートメントB インスタンスA インスタンスB インスタンスC インスタンスD コンパートメントC インスタンスI インスタンスJ インスタンスK インスタンスL インスタンスE インスタンスF インスタンスG インスタンスH
42. コンパートメントは、親コンパートメントから子コンパートメント、孫コン パートメントへと階層構造に従ってポリシーを継承する • 例1 : デフォルトから存在する以下の管理者ポリシーはルート・コンパート メントに存在するため、継承により管理者グループはテナント内の全ての コンパートメントの管理権限を持つ • Allow group Administrators to manage all-resources in tenancy • 例2 : 以下のポリシーがコンパートメントAにある場合、NetworkAdminグ ループのメンバーは、継承によりコンパートメントCのVCNの管理権限も 持つ • Allow group NewtworkAdmins to manage virtual-network-family in compartment B ポリシーの継承 Copyright © 2024 Oracle and/or its affiliates. 46 Tenancy (root compartment) A B C
43. ポリシーを作成する際には、必ずどこかのコンパートメント(またはルート・ コンパートメント)に作成する必要がある ポリシーが存在する場所(コンパートメント)により、誰がそれを変更/削除で きるかが決まってくる(制御できる) • コンパートメントBに存在するポリシーは、コンパートメントBの管理者 (や、その上位のコンパートメントAやテナンシーの管理者)が変更できる • つまり、コンパートメントBの管理権限を付与する場合は、コンパートメ ントBに作成するのではなく、より上位のコンパートメントであるAまたは テナンシーにポリシーを作成するのが望ましい • Allow group B-admin to manage all-resources in compartment B ポリシーの存在場所 Copyright © 2024 Oracle and/or its affiliates. 47 Tenancy (root compartment) A B C
44. Copyright © 2024 Oracle and/or its affiliates. 48 コンパートメントの移動 Moving Compartments
45. 1. リソースを個別に別コンパートメントに移動 • リソース単位で個別に指定してコンパートメ ントを移動する方法 • ほとんどのリソースが対応している(全部では ない) 2. リソースをコンパートメントごと別階層に移動 • コンパートメントを指定して一括で移動 • 以下の場合は移動不可 • 移動先に同じ名称のコンパートメントがある • 移動先の親コンパートメントが同じ名前 コンパートメント移動の2つの方法 Copyright © 2024 Oracle and/or its affiliates. 49 テナンシー (Root Compartment) A B C C
46. ポリシーが移動前と移動後に共通となる親コンパートメント(またはそれ以上の階層)に存在し、かつその ポリシーが移動対象のコンパートメントを直接指定している場合は、コンパートメント移動時にポリ シーが自動的に更新される コンパートメント移動時のポリシーの動き Copyright © 2024 Oracle and/or its affiliates. 50 Tenancy (root compartment) Ops Test Dev A Tenancy (root compartment) Ops Test Dev A A Allow group G1 to manage instance-family in compartment Test:A Allow group G1 to manage instance-family in compartment Test:A Dev:A ポリシーが自動で更新され るため、G1グループのメン バーは引き続きAコンパー トメントにアクセス可能 コンパートメンとAをTest 配下からDev配下に移動 G1 G1 G1
47. ポリシーが移動対象のコンパートメントを直接指定せず、上の階層を指定している場合は、コンパート メント移動時にポリシーは更新されないため、移動後の階層構造の影響を受けてアクセス権が変わる コンパートメント移動時のポリシーの動き(続き) Copyright © 2024 Oracle and/or its affiliates. 51 Tenancy (root compartment) Ops Test Dev A Tenancy (root compartment) Ops Test Dev A A Allow group G1 to manage instance-family in compartment Test Allow group G1 to manage instance-family in compartment Test ポリシーは自動で更新され ないため、G1グループのメ ンバーはAコンパートメン トにアクセスできなくなる コンパートメンとAをTest 配下からDev配下に移動 G1 G1
48. Copyright © 2024 Oracle and/or its affiliates. 52 IAMの設計リファレンス Reference IAM model for Enterprises
49. 2. リソース・プリンシパル 1. ユーザー クライアント OCIは、全てがAPIのコールに よって動作し、その実行時に認 証/認可が行われるようなアーキ テクチャになっている (コンソー ル画面でもAPIがコールされる) OCIの3つのプリンシパルそれぞ れからのAPIアクセスについて、 認証、および認可をどう設計し ていくかが鍵となる 1. ユーザー 2. リソース(インスタンス)プ リンシパル 3. サービス・プリンシパル OCIにおいて認証/認可の付与は、APIコールに対して行われる Copyright © 2024 Oracle and/or its affiliates. 53 API Endpoint OCI Console on Browser OCI-CLI SDK OCI Region VCN API Caller Compute インスタン ス OCIリソース (DBCSなど) OCIリソース (ATPなど) API Caller API Caller 3. サービス・ プリンシパル OCI サービス
50. 「認証」をどうするか = サインインできるかどう か • ユーザー・プリンシパル • ユーザー毎に、コンソール操作、APIコールのう ち一部を無効化することができる • アクセス元ネットワークによる制限、多要素認証 などの活用も検討(サインオン・ポリシー) • システム・ユーザーとしての利用はできる限り行 わないことを推奨、できる限りリソース・プリン シパルを利用する(例外 ExadataCSのbkup_apiな ど) • リソース・プリンシパル • OCI上のインスタンス上に配置したプログラムか らのAPIコール • サービス・プリンシパル ->考慮不要 • ユーザーによる認証設定は不可 「認可」をどうするか = リソースにアクセスでき るかどうか • ユーザー・プリンシパル • グループ単位で権限を設定 : Allow group A to XXX • アクセス元のネットワーク制限の考慮が必要な場 合はネットワーク・ソース機能の利用を検討 • リソース・プリンシパル • 動的グループ単位で権限を設定 : Allow dynamic- group B to XXX • コンパートメントと組み合わせで対象を制御でき る • ネットワーク・ソース機能を利用してソース元 VCNの制限も可能 • サービス・プリンシパル • 利用するサービス毎に個別に設定 • (例)Oracle Content Experienceによるリソース作成 IAMをどう設計するか? – 認証、認可それぞれプリンシパル毎に考える Copyright © 2024 Oracle and/or its affiliates. 54
51. ユーザー・プリンシパルへの権限付与 • (例) 社内ネットワークとVCNからの操作(コンソール、API)を許可する • allow group A to manage objects in compartment X where request.vcn.id = '<my_vcn_id>' • allow group A to manage objects in compartment X where request.networksource.name = '<my_onprem_network>' リソース・プリンシパルへの権限付与 • (例) 特定コンパートメントのインスタンスからの操作を許可する • allow dynamic group <特定コンパートメントを示す動的グループ* > to manage objects in compartment X • (例) ATPインスタンスに、オブジェクトストレージへのバックアップの出力を許可する • allow dynamic group <ATPを動的グループ化> to manage objects in compartment サービス・プリンシパルへの権限付与 • allow service XXX to use Object Storageへのアクセスの設定例 Copyright © 2024 Oracle and/or its affiliates. 55 * 動的グループを以下のように表記することで、特定コンパートメント内のリ ソースとインスタンスを一括で動的グループに指定することができる Match any rules defined below Rule 1: ALL {resource.compartment.id='<コンパートメントのOCID>'} Rule 2: ALL {instance.compartment.id='<コンパートメントのOCID>'}
52. ユーザー・プリンシパルに対するポリシー付与 許可しても問題ないケース • 既に評価済のリソースに対する権限を、プロジェクトのコンパートメントの範囲内でのみ利用する場合 • allow group Project-A-admins to manage instances in compartment Project-A 本当に必要な場合を除き原則的に禁止するべきケース* • アクセス対象が、プロジェクトのコンパートメントの枠を超える場合 • allow group Project-A-admins to manage <New-Services> in compartment Project-B • allow group Project-A-admins to manage <New-Services> in tenancy 禁止するべきケース • 禁止されたリソースへのアクセスの場合(例 : インターネット・ゲートウェイ) • allow group Project-A-admins to manage internet-gateways in compartment Project-A * ただし、一部のOCIサービスは、管理作業のためにテナンシレベルのアクセス権限を持つ権限が必要なサービスがあ り、その場合はプロジェクトにテナンシレベルの権限を付与するか、それとも権限は与えずに管理作業を中央で代行 するかはサービス毎に検討が必要 (そのような場合も、ほとんどのサービスで利用権限はコンパートメント単位で付 与が可能) • 例 : Cloud Guard、Data Safe、Log Analyticsなど 申請に基づくポリシー許可の基本的な考え方 (案) Copyright © 2024 Oracle and/or its affiliates. 56
53. サービス・プリンシパルに対するポリシー付与 許可しても問題ないケース • サービスが、当該プロジェクトのコンパートメントの禁止されていないリソースに対してアクセスする場合 • Allow service CEC to manage objects in compartment Project-A 禁止するべきケース • そもそも利用が禁止されたサービスの場合 (今の所例は思い浮かばないが、もしあれば) • allow service <Dangerous-Service> to manage instances in compartment A • サービスが、禁止されているリソースを作成する権限を要求する場合 • allow service <New-service> to manage internet-gateways in compartment A • アクセス対象が、プロジェクトのコンパートメントの枠を超える場合* • allow service <New-servce> to manage instances in compartment B * ただし、そのサービスが安全であると分かっている場合は、テナンシレベルでの許可を予め付与しておくことで、 省力化を図ることもできます 申請に基づくポリシー許可の基本的な考え方 (案) Copyright © 2024 Oracle and/or its affiliates. 57
54. リソース・プリンシパルに対するポリシー付与 許可しても問題ないケース • コンパートメントに対して定義済の動的グループに対し、当該プロジェクトのリソースの、許可されたリソース へのアクセスを付与する場合 • allow dynamic group Project-A-Resources to manage instances in compartment A 本当に必要な場合を除き原則的に禁止するべきケース • 定義済の動的グループ以外の動的グループ(特にプロジェクト外のコンパートメントのリソース)に対してリソース のアクセス権を付与する場合 • allow dynamic group Project-B-Resources to manage instances in compartment Project-A • アクセス対象が、プロジェクトのコンパートメントの枠を超える場合 • allow dynamic group Project-A-Resources to manage instances in compartment Project-B • allow dynamic group Project-A-Resources to manage instances in tenancy 基本的に禁止するべきケース • 禁止されたリソースへのアクセスの場合(例 : インターネット・ゲートウェイ) • allow dynamic group Project-A-Resources to manage internet-gateways in compartment Project-A 申請に基づくポリシー許可の基本的な考え方 (案) Copyright © 2024 Oracle and/or its affiliates. 58
55. 人による全てのアクセスは、実績のある認証メカニズムと管理機能（パスワードの複雑さ/ ローテーション等）を活用するために、顧客の企業アイデンティティプロバイダ（IdP）との 連携を介して行う 認証とユーザ管理の設計 59 ユースケース 利用する機能 人によるアクセス（コンソール利用） 企業IdPとOCI IAM間でSAML2.0 フェデレーション 人によるアクセス（CLI/SDK利用） APIキーを使用してOCI IAMユーザを作成 人によるアクセス（PaaS/SaaSアプリケーション 経由） 企業IdPとOCI IAM間でSAML2.0 フェデレーション OCIインスタンス上で動作するアプリケーション インスタンス・プリンシパル OCI外で動作するアプリケーション APIキーを使用してOCI IAM「ユーザ」を作成 *この場合「ユーザ」は人ではなくソフトウェア・エージェン ト フェデレーションが失敗した際の人間によるアク セス フェデレーションの『Bleak-glass』シナリオを設定 (このケース以外でOCI IAMユーザがコンソールパスワードを使 用することはないようにする) Copyright © 2024 Oracle and/or its affiliates.
56. 各リソースは単一のコンパートメントに属するが、コンパートメントをまたいで接続・共有す ることは可能 • 例：VCNとそのサブネットは異なるコンパートメントに存在可能 コンパートメントは作成・名前変更後に削除可能 最大6階層までのサブ・コンパートメントを持つことが可能 • 子コンパートメントは上位のコンパートメントのパーミッションを引き継ぐ コンパートメント作成後に最低1つのポリシーを書かないと、コンパートメント内のリソース にアクセスできない（管理者やテナンシー全体にパーミッションのあるユーザは除く） コンパートメントの設計 60 Copyright © 2024 Oracle and/or its affiliates.
57. コンパートメント: NetworkInfra • ネットワーク管理者が一元的に管理する重要なネットワークイン フラストラクチャ • リソース: トップレベルの VCN、セキュリティリスト、インター ネットゲートウェイ、DRG コンパートメント: Dev、Test、Prod Networks • ネットワークを使用できるユーザーに関するポリシーを簡単に記 述するための別のコンパートメントとしてモデル化 • リソース: サブネット、データベース、ストレージ (共有している 場合) コンパートメント: Project • 特定のチームまたはプロジェクトで使用されているリソース。分 散管理の目的で分離 • リソース: コンピューティングインスタンス、データベース、ブ ロックボリュームなど • 独自の DevOps 環境を必要とするチームごとに1つコンパートメ ントを作成 コンパートメントの設計例 Copyright © 2024 Oracle and/or its affiliates. 61 1 2 3 1 2 3
58. グループとポリシーの設定 Copyright © 2024 Oracle and/or its affiliates. 62 テナンシ グループ NetworkAdmins (Tanaka) ProjectAコンパートメント • Allow group NetworkAdmins to MANAGE virtual- netwoQrk-family in compartment NetworkInfra • Allow group NetworkAdmins to manage instance- family in compartment NetworkInfra • Allow group A-Admins to USE virtual-network- family in compartment NetworkInfra • Allow group A-Admins to manage all-resources in compartment ProjectA • NetworkAdminsグループのTanakaさんがNetworkInfra コンパートメントにネットワークを作成 • A-AdminsグループのSatoさんは、NetworkInfra コンパートメント内のVCNを使用してProjectA コンパートメントにインスタンスを起動 グループ A-Admins (Sato) NetworkInfraコンパートメント Satoさんが起動したインスタンスはネットワーク観点からはVCNに存在するが、アクセスの観点から はVCNが存在するNetworkInfraコンパートメントではなくProjectAコンパートメントにある
59. コンパートメント単位での管理者を任命する場合 テナンシ管理者の役割 • ユーザーの作成 • グループの作成(コンパートメントの管理者グ ループ、コンパートメントのユーザーグルー プ) • コンパートメント管理者の任命 • コンパートメントの作成 • テナンシレベルのポリシーの設定 • Allow group com-A-admins to use users in tenancy • Allow group comp-A-admins to manage groups in tenancy where target.group.name='comp-A-users' • Allow group comp-A-admins to manage policies where target.compartment.name = 'comp-A' コンパートメント管理者の役割 • 管理下のコンパートメントの利用ユーザーの アサイン • コンパートメントの中のポリシーの設定 • 例えば特定のリソースのみが扱えるユーザーの設 定など • Allow group comp-A-users to use all- resources in compartment comp-A ポリシーの設定例 Copyright © 2024 Oracle and/or its affiliates. 63
60. Copyright © 2024 Oracle and/or its affiliates. 64 クロステナンシ・ポリシー Cross Tenancy Policies
61. テナンシをまたいで権限付与を行う際に必要な特殊なポリシー • 自テナンシ以外の他のテナンシと連携して操作する場合にはクロステナンシ・ポリシーが必要 • クロステナンシ・ポリシーの構文 • Define: 自テナンシ以外のリソースに対して、そのポリシー内での名前を決めるための構文。その後ろに続くEndorse文や Admit文の中で指定する名前（テナンシ名およびグループ名）を定義する。ここで定義する名前は、実際のリソース名とは異 なっていてもよい。 • Endorse: 自テナンシ内のグループが他のテナンシ内で実行できる操作を支持するという意味。 • Admit: 他のテナンシからEndorseされたグループに対して、自テナンシでの権限付与を認めるという意味。EndorseとAdmit は対になっている必要がある。 • Defineは、EndorseまたはAdmitステートメントと同じポリシー・エンティティで、EndorseやAdmitよりも先に記 載する必要がある。 • クロステナンシのポリシーはrootコンパートメントの直下に作成する必要がある。 クロステナンシ・ポリシーとは Copyright © 2024 Oracle and/or its affiliates. 65 テナンシA テナンシB 隣のテナンシをテナンシBという名前で 定義して、そのテナンシBの中のオブ ジェクトストレージを、うちのテナンシ のグループの人が操作できるようにさせ ることを支持します。 Define tenancy テナンシB as ocid1.tenancy.oc1..<unique_ID> Endorse group StorageAdmins to manage object-family in tenancy テナンシB 隣のテナンシをテナンシAという名前で 定義し、隣のテナンシのグループをグ ループAという名前で定義して、そのグ ループにうちのオブジェクトストレージ を操作させることを認めます。 Define tenancy テナンシA as ocid1.tenancy.oc1..<unique_ID> Define group グループA as ocid1.group.oc1..<unique_ID> Admit group グループA of tenancy テナンシA to manage object-family in tenancy グループA
62. 異なるテナンシのDRG同士でリモートピアリング接続を行う場合 クロステナンシ・ポリシーの例 Copyright © 2024 Oracle and/or its affiliates. 66 Define tenancy Acceptor as <テナンシBのOCID> Allow group <テナンシAのグループ名> to manage remote-peering-from in compartment <テナンシAのコンパートメント名> Endorse group <テナンシAのグループ名> to manage remote-peering-to in tenancy Acceptor Define tenancy Requestor as <テナンシAのOCID> Define group GroupA as <テナンシAのグループのOCID> Admit group GroupA of tenancy Requestor to manage remote-peering-to in compartment <テナンシBのコンパートメント名> テナンシA Remote Peering Connection DRG テナンシB DRG テナンシA（RPCのリクエストを行う側）で作成するポリシー テナンシB（RPCのリクエストを受信する側）で作成するポリシー
63. クロステナンシでの操作が可能な機能は各サービスのドキュメントに記載されている [Object Storage] テナンシをまたがったオブジェクト・ストレージ・リソー スへのアクセス • https://docs.oracle.com/ja- jp/iaas/Content/Object/Concepts/accessingresourcesacrosstenancies.htm [DRG, VCN] DRGクロステナンシ・リモート・ピアリング、テナンシ間の VCNアタッチメント • https://docs.oracle.com/ja-jp/iaas/Content/Network/Tasks/drg-iam.htm [DNS] テナンシ間のDNSリソースの管理 • https://docs.oracle.com/ja-jp/iaas/Content/DNS/dns-cross-tenancy.htm [Monitoring] モニタリング・メトリック • https://docs.oracle.com/ja- jp/iaas/Content/Security/Reference/monitoring_security.htm#metric-cross- tenancy [Streaming] テナンシをまたがったストリーミング・リソースへのアクセス • https://docs.oracle.com/ja-jp/iaas/Content/Streaming/Tasks/accessing- streaming-resources-across-tenancies.htm [OKE] テナンシ間のクラスタ関連リソースへのアクセス • https://docs.oracle.com/ja- jp/iaas/Content/ContEng/Concepts/contengaccessingokeresourcesacrosstena ncies.htm [Block Volume] 複数のテナンシにわたるOracle Cloud Infrastructureボリュー ム・データの移行 • https://docs.oracle.com/ja/solutions/migrate-data-across- tenancies/index.html#GUID-81B450A8-4E7B-4846-A31D-3CBE67291338 [Service Connector Hub] クロス・テナンシ・コネクタ・アクセス • https://docs.oracle.com/ja- jp/iaas/Content/Security/Reference/sch_security.htm#connector- cross-tenancy [Logging Analytics] オブジェクト・ストレージからのクロステナンシ・ログ 収集の許可 • https://docs.oracle.com/ja-jp/iaas/logging-analytics/doc/collect-logs-your- oci-object-storage-bucket.html#LOGAN-GUID-BD41DB70-7865-4D86-8EED- 0C9EAA9BF0F6 [Logging Analytics] OCIロギング・サービスからのクロステナンシ・ログ収 集の許可 • https://docs.oracle.com/ja-jp/iaas/logging-analytics/doc/ingest-logs-other- oci-services-using-service-connector.html#LOGAN-GUID-5802C5BC-82A7- 496E-86FB-2B1FB8284815 [Data Labeling] クロス・テナンシ・ポリシーの設定 • https://docs.oracle.com/ja-jp/iaas/data-labeling/data- labeling/using/getting-started.htm [Data Flow] クロス・テナンシ・アクセス • https://docs.oracle.com/ja-jp/iaas/data- flow/using/dfs_getting_started.htm#cross-tenancy-access [データ統合] オブジェクトのエクスポートおよびインポート • https://docs.oracle.com/ja-jp/iaas/data-integration/using/export- import.htm [NoSQL Database] テナンシをまたがったNoSQL表へのアクセス • https://docs.oracle.com/ja-jp/iaas/nosql-database/doc/managing-access- クロステナンシ・ポリシーのユースケース Copyright © 2024 Oracle and/or its affiliates. 67
64. Copyright © 2024 Oracle and/or its affiliates. 68 参考情報 References
65. 日本語マニュアル – IAM • https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/overview.htm IAMリソースのサービス制限値 • https://docs.oracle.com/en-us/iaas/Content/General/Concepts/servicelimits.htm Best Practices for Identity and Access Management (IAM) in Oracle Cloud Infrastructure • https://cloud.oracle.com/iaas/whitepapers/best-practices-for-iam-on-oci.pdf IAM 関連の技術情報 Copyright © 2024 Oracle and/or its affiliates. 69
66. Oracle Cloud Infrastructure マニュアル (日本語 / 英語) • https://docs.cloud.oracle.com/iaas/api/ - APIリファレンス • https://docs.cloud.oracle.com/ja-jp/iaas/Content/General/Reference/aqswhitepapers.htm - テクニ カル・ホワイト・ペーパー • https://docs.cloud.oracle.com/iaas/releasenotes/ - リリースノート • https://docs.cloud.oracle.com/ja-jp/iaas/Content/knownissues.htm - 既知の問題(Known Issues) • https://docs.cloud.oracle.com/ja-jp/iaas/Content/General/Reference/graphicsfordiagrams.htm - OCIアイコン・ダイアグラム集(PPT、SVG、Visio用) ※ 日本語版は翻訳のタイムラグのため情報が古い場合があります。最新情報は英語版をご確認ください Oracle Cloud Infrastructure マニュアル・ドキュメント Copyright © 2024 Oracle and/or its affiliates. 70
67. Oracle Cloud Infrastructure 活用資料集 • https://oracle-japan.github.io/ocidocs チュートリアル - Oracle Cloud Infrastructureを使ってみよう • https://oracle-japan.github.io/ocitutorials Oracle Cloud ウェビナーシリーズ • https://www.oracle.com/goto/ocws-jp Oracle 主催 セミナー、ハンズオン・ワークショップ • https://www.oracle.com/search/events/_/N-2bu/ Oracle Cloud Infrastructure – General Forum (英語) • https://cloudcustomerconnect.oracle.com/resources/9c8fa8f96f/summary Oracle Cloud Infrastructure トレーニング・技術フォーラム Copyright © 2024 Oracle and/or its affiliates. 71
68. Thank you 72 Copyright © 2024 Oracle and/or its affiliates.