Oracle Cloud Infrastructureドキュメント

アクセス制御

このトピックでは、コンパートメントおよび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へ接続する許可を与え、単一のリージョン内でピアリング関係を形成するためのものです。 詳細は、「ローカルVCNピアリング(リージョン内)」を参照してください。

同様に、virtual-network-familyに含まれるremote-peering-connectionsというリソース・タイプがあり、リモートVCNピアリングに関連する他の2つのリソース・タイプ(リージョン間)が含まれています:

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

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

異なる動詞のニュアンス

必要に応じて、別のポリシー動詞(manageuseなど)を使用してアクセス・レベルを制限するポリシーを作成できます。 それを行うと、ネットワーキングのポリシー動詞について理解するためのニュアンスがあります。

inspect動詞は、クラウド・ネットワーク・コンポーネントに関する一般的な情報(セキュリティ・リストの名前やOCID、ルート表など)を返すだけではないことに注意してください。 また、コンポーネントの内容も含まれます(たとえば、セキュリティ・リストの実際のルール、ルート表のルートなど)。

また、以下のタイプの能力は、manage verbでは使用できず、use verbでは使用できません:

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

重要

各VCNには、ネットワークの動作(ルート表、セキュリティ・リスト、DHCPオプション、インターネット・ゲートウェイなど)に直接影響を及ぼすさまざまなコンポーネントがあります。
これらのコンポーネントの1つを作成すると、そのコンポーネントとVCNとの間の関係が確立されます。つまり、ポリシーでコンポーネントの作成とVCN自体の管理を許可する必要があります。 ただし、コンポーネントの変更(ルート・ルール、セキュリティ・リスト・ルールなどの変更)を行うためにコンポーネントを変更することは、ネットワークの動作に直接影響する可能性がある場合でも、VCN自体を管理する権限を必要としません。 この不一致は、ユーザーに最小限の特権を与える柔軟性を提供し、ユーザーがネットワークの他のコンポーネントを管理できるように、VCNへの過度のアクセスを許可する必要はありません。 特定のタイプのコンポーネントを更新する機能を他の人に与えることで、ネットワークの動作を制御することで暗黙的にそのコンポーネントを信頼していることに注意してください。

ポリシー動詞の詳細については、「動詞」を参照してください。