アクセス制御

このトピックでは、コンパートメントおよびIAMポリシーを使用したクラウド・ネットワークへのアクセスの制御に関する基本情報を示します。

コンパートメントとクラウド・ネットワーク

仮想クラウド・ネットワーク(VCN)やコンピュート・インスタンスなどのクラウド・リソースを作成する際は、リソースを配置するIAMコンパートメントを指定する必要があります。コンパートメントは、組織の管理者から権限を付与された特定のグループのみがアクセスできる関連リソースの集合です。管理者は、コンパートメントおよび組織のどのユーザーがどのコンパートメントにアクセスするかを制御するIAMポリシーを作成します。最終的に、各ユーザーが必要なリソースのみにアクセスできるようにすることが目標です。

Oracle Cloud Infrastructureの試用の場合は、VCNおよびそのコンポーネントの作成および管理、VCNへのインスタンスの起動およびこれらのインスタンスへのブロック・ストレージ・ボリュームのアタッチを必要とするのはほんの数人のみです。この数人のユーザーは、これらのすべてのリソースにアクセスする必要があるため、これらのリソースのすべてが同じコンパートメント内に配置されます。

VCNを使用した企業の本番環境では、特定のタイプのリソースへのアクセスの制御を容易にするために複数のコンパートメントを使用できます。たとえば、管理者は、VCNおよび他のネットワーキング・コンポーネント用にCompartment_Aを作成します。また、HR組織が使用するすべてのコンピュート・インスタンスおよびブロック・ストレージ・ボリューム用にCompartment_Bを作成し、マーケティング組織が使用するすべてのインスタンスおよびブロック・ストレージ・ボリューム用にCompartment_Cを作成します。この場合、管理者は、各コンパートメントでユーザーが必要とするレベルのアクセスのみをユーザーに付与するIAMポリシーを作成します。たとえば、HRインスタンスの管理者は既存のクラウド・ネットワークを変更する権限は付与されません。そのため、Compartment_Bに対しては完全な権限を持ちますが、Compartment_Aへのアクセスは制限されます(ネットワークにインスタンスを起動するのに必要な権限のみ)。Compartment_A内の他のリソースを変更しようとすると、リクエストは拒否されます。

VCN、サブネット、ルート表、セキュリティ・リスト、サービス・ゲートウェイ、NATゲートウェイ、VPN接続およびFastConnect接続などのネットワーク・リソースは、あるコンパートメントから別のコンパートメントに移動できます。リソースを新しいコンパートメントに移動すると、固有のポリシーがただちに適用されます。

コンパートメントとクラウド・リソースへのアクセスの制御方法の詳細は、 テナンシの設定およびOracle Cloud Infrastructure Identity and Access Managementの概要を参照してください。

ネットワーキングに対するIAMポリシー

ネットワーキングにアクセス権を付与する最も簡単な方法は、ネットワーク管理者によるクラウド・ネットワークの管理で示されているポリシーです。この対象は、クラウド・ネットワークおよびその他すべてのネットワーキング・コンポーネント(サブネット、セキュリティ・リスト、ルート表、ゲートウェイなど)です。ネットワーク管理者が(ネットワーク接続をテストするための)インスタンスを起動できるようにするには、ユーザーによるコンピュート・インスタンスの起動を参照してください。

ポリシーを初めて使用する場合は、ポリシーの開始共通ポリシーを参照してください。

ネットワーキングに対する詳細なポリシーを記述するための参照資料については、コア・サービスの詳細を参照してください。

個々のリソース・タイプ

必要に応じて、広範なvirtual-network-familyのかわりに、個々のリソース・タイプ(たとえば、セキュリティ・リストのみ)を対象としたポリシーを記述できます。instance-familyリソース・タイプには、サブネット内にあり、インスタンスにアタッチしているVNICに対するいくつかの権限も含まれています。詳細は、動詞とリソース・タイプの組合せの詳細および仮想ネットワーク・インタフェース・カード(VNIC)を参照してください。

local-peering-gatewaysと呼ばれるリソース・タイプはvirtual-network-familyに含まれ、(リージョン内の)ローカルVCNピアリングに関連する2つのリソース・タイプを含みます:

  • local-peering-from
  • local-peering-to

local-peering-gatewaysリソース・タイプは、ローカル・ピアリング・ゲートウェイ(LPG)に関連するすべての権限を対象とします。local-peering-fromおよびlocal-peering-toリソース・タイプは、2つのLPGを接続して1つのリージョン内でピアリング関係を形成する権限を付与するためのものです。詳細は、ローカル・ピアリング・ゲートウェイを使用したローカルVCNピアリングを参照してください。

同様に、remote-peering-connectionsと呼ばれるリソース・タイプはvirtual-network-familyに含まれ、(リージョン間の)リモートVCNピアリングに関連する2つのリソース・タイプを含みます:

  • remote-peering-from
  • remote-peering-to

remote-peering-connectionsリソース・タイプは、リモート・ピアリング接続(RPC)に関連するすべての権限を対象とします。remote-peering-fromおよびremote-peering-toリソース・タイプは、2つのRPCを接続して、リージョン間でピアリング関係を形成する権限を付与するためのものです。詳細は、Remote VCN Peering using an RPCを参照してください。

異なる動詞の違い

必要に応じて、異なるポリシー動詞(manageuseなど)を使用してアクセス・レベルを制限するポリシーを記述できます。これを行う場合、ネットワーキングのポリシー動詞について理解する必要がある微細な違いがいくつかあります。

inspect動詞では、クラウド・ネットワークのコンポーネントに関する一般情報(セキュリティ・リストまたはルート表の名前とOCIDなど)が戻されるのみではありません。コンポーネントのコンテンツ(たとえば、セキュリティ・リスト内の実際のルール、ルート表内のルートなど)も含まれます。

また、次のタイプの機能はmanage動詞でのみ使用でき、use動詞では使用できません:

  • internet-gatewaysの更新(有効化/無効化)
  • security-listsの更新
  • route-tablesの更新
  • dhcp-optionsの更新
  • 仮想クラウド・ネットワーク(VCN)への動的ルーティング・ゲートウェイ(DRG)のアタッチ
  • DRGと顧客構内機器(CPE)の間のIPSec接続の作成
  • VCNのピアリング
重要

各VCNには、ネットワークの動作に直接影響する様々なコンポーネント(ルート表、セキュリティ・リスト、DHCPオプション、インターネット・ゲートウェイなど)があります。これらのコンポーネントのいずれかを作成する場合、そのコンポーネントとVCNの間の関係を確立します。つまり、コンポーネントの作成とVCN自体の管理の両方がポリシーで許可されている必要があります。ただし、そのコンポーネントを更新する(ルート・ルールやセキュリティ・リスト・ルールの変更など)機能は、コンポーネントを変更するとネットワークの動作に直接影響することがありますが、VCN自体を管理する権限を必要としません。この齟齬は、ユーザーに最低限の権限を付与する柔軟性を提供するためのものです。これによって、ユーザーがネットワークの他のコンポーネントを管理できるようにするためだけに、VCNへの必要以上のアクセス権を付与せずに済みます。あるユーザーが特定のタイプのコンポーネントを更新できるようにするということは、そのユーザーを暗黙的に信頼し、ネットワークの動作の制御を任せていることになるということに注意してください。

ポリシー動詞の詳細は、ポリシーの基本を参照してください。