Oracle Cloud Infrastructureのリソースおよびサービス
Oracle Cloud Infrastructure (OCI)は、リソースを管理できる様々なリソースおよびサービスを提供します。OCIサービスおよびその方法で組織がガバナンス・モデルを実装できるようにする方法を説明します。
リソース
Oracle Cloud Infrastructure (OCI)を使用すると、リソースを編成し、組織内のガバナンスを実装できます。OCIリソースとサービスの物理的および論理的な組織について学習します。
リージョン
OCIは、地理的なリージョンと可用性ドメインに物理的にホストされます。リージョンは限定された地理的領域で、可用性ドメインはリージョン内に配置された1つ以上のデータ・センターです。
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含むローカライズされた地理的領域です。地方は他の地域から独立し、たくさんの距離(国や大陸など)を分けることができます。
1つのリージョンは、1つ以上の可用性ドメインで構成されます。OCIリソースは、仮想クラウド・ネットワークのようにリージョン固有であるか、コンピュート・インスタンスのように可用性ドメイン固有です。
可用性ドメイン
アベイラビリティ・ドメインは、リージョン内のスタンドアロンで独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。アベイラビリティ・ドメインは電源や冷却、内部アベイラビリティ・ドメイン・ネットワークなどのインフラを共有しません。そのため、1つの可用性ドメインで障害が発生しても、リージョン内の他の可用性ドメインには影響しません。
クラウド・サービスを構成する場合、複数のアベイラビリティ・ドメインを使用して、高可用性を確認し、リソース障害から保護します。インスタンスやそれに接続されたストレージ・ボリュームなど、同じ可用性ドメイン内に一部のリソースを作成する必要があることに注意してください。
フォルト・ドメイン
フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラのグループです。アベイラビリティ・ドメインごとに3つのフォルト・ドメインがあり、独立した電源とハードウェアです。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションは、物理サーバーの障害、システムのメンテナンス、およびフォルト・ドメイン内の電源障害を許容できます。
たとえば、1つのフォルト・ドメインに影響するハードウェア障害またはコンピュート・ハードウェア・メンテナンス・イベントは、他のフォルト・ドメインのインスタンスに影響しません。
リソースの識別
OCIリソースを識別する基本概念は、OCID (Oracle Cloud Identifier)です。リソースに関するメタデータを含むOracle Cloud Infrastructure (OCI)サービスのリソースを識別する一意の識別子です。リソースは、ユーザーまたはグループ、インスタンスまたはサービスです。サービスまたはプリンシパルのインスタンスであるリソースは、特定のリソースの完全なOCIDのコンポーネントです。
OCIでは、組織でガバナンスを実装する際に、OCIDを使用してリソースのポリシーを識別し、適用します。次に、OCIDの構文とそのコンポーネントを示します。
Oracle Cloud Infrastructureには、クラウド・リソースの作成、編成および管理を可能にする次のサービスが用意されています。
ocid1.<RESOURCE TYPE>.<REALM>.[REGION][.FUTURE USE].<UNIQUE
ID>
- OCID1: OCIDのバージョンを示すリテラル文字列。
- リソース・タイプ:インスタンス、VCN、ユーザーまたはグループなどのリソースのタイプ。
- レルム:レルムは、商用レルムにoc1、政府クラウドにoc2、連邦政府にoc3などのエンティティを共有する一連のリージョンです。
- リージョン:リソースの居住地の地理的リージョン(phx、iadなど)にあります。
- 将来使用:リソースを将来使用するために予約するかどうかを指定します。
- 一意のID: IDの一意の部分。
テナント
テナンシは、Oracle Cloud Infrastructureのサインアップ時にOracleがOracle Cloud内で設定するセキュアで分離されたパーティションです。テナンシ内のOracle Cloudでリソースを作成、整理および管理できます。テナンシは、会社または組織と同義です。通常、会社は1つのテナンシを持ち、そのテナンシ内の組織構造を反映します。単一のテナンシは通常1つのサブスクリプションに関連付けられており、1つのサブスクリプションには通常1つのテナンシのみが含まれます。
テナンシ内のテナンシ構造内の各リソースは、定義されたガバナンス・モデルに準拠するようにリソースを論理的にグループ化および管理できるようにするコンパートメント(例外が少なく)に属します。リソースは、IaaS、PaaSおよびインフラストラクチャ・コンポーネントに関連するテナンシにプロビジョニングされますが、仮想クラウド・ネットワーク(VCN)、サブネット、セキュリティおよびルーティング・ルールに制限されません。
ほとんどのコア・リソースは、テナンシ内のコンパートメントに属します。ただし、コンパートメントの外部でグローバルおよびライブのコア・リソースがあります。
区分
コンパートメントは、Oracle Cloud Infrastructureテナンシ内のリージョン間論理パーティションです。コンパートメントを使用して、Oracle Cloudでリソースを編成し、リソースへのアクセスを制御し、使用割当てを設定します。特定のコンパートメント内のリソースへのアクセスを制御するには、誰がリソースにアクセスできるか、および誰が実行できるアクションを指定するポリシーを定義します。
適切に設計されたコンパートメントによって、組織は次のことを実行できます。
- コンパートメント別のアクセスを制御することで、職務分掌を徹底し、ネットワーキング・リソースやデータベースなどの機能に基づいてアクセスを制御
- 管理権限をコンパートメント管理者に委任して、それぞれのリソースを管理します
- 各コンパートメントに基づいて、部門別にチャージバック・モデルを作成します
- コンパートメントに基づいた割当ておよびバッジの定義
サービス制限
OCIにサインインすると、テナンシにサービス制限のセットが構成されます。サービス制限は、リソースに対して設定される割当てまたは許容量です。たとえば、テナンシでは、データ・サイエンス・サービス・インスタンスの最大数が許可される場合があります。すべてのリソースには、定義された制限とスコープがあります。テナンシで最初に設定された制限は、部品表で購入したリソースと、デフォルトとして決定された値の組合せに基づきます。サービス制限の範囲は、リージョン別または可用性ドメイン固有のものであるため、柔軟性が向上します。これらの制限は、OCIリソースの使用状況およびアカウントの存続期間に基づいて自動的に増加する場合があります。
予算
予算を指定して、OCI支出に弱い制限を設定できます。予算にアラートを設定して、使用量が予算を超えたときに通知することもできます。OCIコンソールを使用して、すべての予算と支出を1箇所で表示できます。
コンパートメント割当て
コンパートメント割当てにより、テナンシおよびコンパートメント管理者はOCIでリソースをどのように消費するかをより適切に制御できます。割当て制限により、管理者はコンソールを使用してコンパートメントにリソースを簡単に割り当てることができます。コンパートメント割当ては、OCIテナンシの支出を管理するための強力なメカニズムを提供します。
ロギング
- 監査ログ:監査サービスによって発行されるイベントに関連するログ。
- サービス・ログ: APIゲートウェイ、イベント、ファンクション、ロード・バランシング、オブジェクト・ストレージ、VCNフロー・ログなどの個々のサービスによって発行されるログ。
- カスタム・ログ:カスタム・アプリケーション、他のクラウド・プロバイダまたはオンプレミス環境からの診断情報を含むログ。
ログ・グループ
制限されたユーザー・グループへのログへのアクセスを定義/制限するために使用されるログを編成するための論理コンテナ。ログ・データの機密性に基づいて個別のログ・グループを作成できます。
たとえば、セキュリティ、ネットワークおよびアプリケーションという3つのログ・グループを作成します。
- 次に、ログ・グループごとにOCI IAMポリシーを作成し、管理ユーザーにログ・グループからのブログの読取りアクセス権を提供します。
- グループSecOpsがコンパートメント・ロギングのログ・コンテンツを読み取ることを許可します。場所:
target.loggroup.id=’ocid1.loggroup.oc1.<OCIRegion>..<SecurityLogGroupUniqueID>
ログ・アナリティクス
OCIのクラウド・ソリューションで、アプリケーションおよびシステム・インフラストラクチャからすべてのログ・データのインデックス、エンリッチ、集約、探索、検索、分析、関連付け、ビジュアル化および監視を行うことができます。
ログ・アナリティクスには、ログから運用に関するインサイトを得る複数の方法が用意されています。
- ログ・エクスプローラUIの使用
- ログ情報のダッシュボードへの集計
- APIを利用したデータの収集と分析
- 他のOCIサービスとの統合
クラウド・ガード
![cloud-guard-detector-recipe.pngの説明が続きます cloud-guard-detector-recipe.pngの説明が続きます](img/cloud-guard-detector-recipe.png)
図cloud-guard-detector-recipe.pngの説明
Oracle Cloud Guardを使用して、Oracle Cloud Infrastructureでリソースのセキュリティをモニターおよび保守できます。クラウド・ガードでは、ディテクタ・レシピを使用して、セキュリティの弱みについてリソースを調査し、オペレータとユーザーのリスクのあるアクティビティを監視するために定義できます。構成ミスまたはセキュアでないアクティビティが検出されると、クラウド・ガードは、定義できるレスポンダ・レシピに基づいて、修正アクションを推奨し、それらのアクションの実行をサポートします。
検出者レシピ
潜在的なセキュリティ問題を識別するための一連のルール/チェック。Oracleでは、オブジェクト・ストレージ・バケット、コンピュート・インスタンス、VCNインスタンス、IAMユーザーおよびグループ、ロード・バランサ、セキュリティ・リスト、ネットワーク・セキュリティ・グループなどのサービスについて、いくつかのベースライン・ディテクタ・レシピが提供されます。Oracle管理レシピのレシピ・ルールは更新できません。ただし、Oracle管理レシピをクローニングし、ユーザー管理ディテクタ・レシピと呼ばれる新しいレシピを作成できます。
ルールで問題を検出するためのレシピ
- Oracle管理レシピ
- ユーザー管理のレシピ
- 構成ディテクタ・レシピ
- パブリック・バケット
- インスタンスにパブリックIPアドレスがあります
- LB SSL証明書の有効期限が近づいています
- アクティビティ・ディテクタ・レシピ
- ユーザーがグループに追加されました
- コンピュート・インスタンスが削除されました
構成ディテクタ・レシピでは、リソース構成をチェックします。たとえば、ストレージ・バケットがパブリックであるか、VCNにNATゲートウェイまたはインターネット・ゲートウェイが作成されているかを確認します。他のディテクタ・レシピでは、動的グループの作成やVMへのVNICの追加などのアクティビティが検出されます。
レスポンダ・レシピ
検出された問題を修正するか、アクションを要求する通知を送信するためのルールのセット。デフォルトのレスポンダ・レシピには、すべての問題を修正するオプションはありません。ただし、イベントから関数を呼び出すことによって対処できます。是正措置を講じるか、OCI機能から問題を修正します。
ディテクタ・レシピと同様に、Oracle管理レスポンダ・レシピと顧客管理レスポンダ・レシピがあります。顧客管理レスポンダ・レシピは、事前定義済のレスポンダ・ルールの一部を無効にできる、Oracle管理レシピのクローンです。
ターゲット
ターゲットは、クラウド・ガードがチェックする対象の範囲を定義します。これにはコンパートメントのリストが含まれます。コンパートメントをターゲットとして追加すると、クラウド・ガードはすべてのサブコンパートメントもチェックします。ターゲットは、コンパートメント、ディテクタ・レシピおよびレスポンダ・レシピが結び付ける場所で定義されます。
タグ付け
タグには、リソースにアタッチされ、使用状況、コスト、所有権などの属性を定義するメタデータ、キーと値のペアが含まれます。
タグの基本
タグ・ネームスペース(定義済タグにのみ適用可能)
タグ・ネームスペースは、タグのコンテナです。これは名前と、0つ以上のタグ・キー定義で構成されます。タグ・ネームスペースはテナンシ全体で一意です。
タグ・キー
タグを参照するために使用する名前。タグ・キーはネームスペース全体で一意です。
タグ値のタイプ
値に許可されるデータ型を指定します。サポートされているデータ型は、文字列と文字列の2つです。
タグ値
ユーザーがタグに適用する値です。一部のタグには事前定義済の値があります。ユーザーは、他のタグの値リストから1つの値を選択する必要があります。
リソースはコンパートメント上のサービスのインスタンスであり、1つ以上のタグを持つことができます。コンパートメントに割り当てられたタグは、コンパートメント内のすべてのリソースに割り当てられます。
リソースにタグを割り当てるには、2つの方法があります。
定義されたタグ
管理者がメタデータを管理する事前定義タグがより一般的に使用されます。たとえば、リソース・メタデータを作成してリソースを管理したり、データを収集したりするには、定義済のタグを使用できます。定義済タグには、使用方法および値の割当て方法に基づいて3つのタイプがあります。
-
事前定義済の値を含むタグ
値リストを作成し、そのリストをタグ・キー定義に関連付けることができます。ユーザーがリソースにタグを適用するときは、事前定義済値リストから値を選択する必要があります。事前定義済の値のリストを使用して、ユーザーがタグに適用できる値を制限します。
-
コスト・トラッキング・タグ
リソース使用のコストを管理するために予算を設定するときに使用されるタグ。
-
タグのデフォルト
特定のコンパートメントで作成されたすべてのリソースに適用されるデフォルト・タグを定義できます。タグのデフォルトを設定すると、リソースを作成するユーザーがタグ・ネームスペースへのアクセス権を持つことなく、適切なタグがリソース作成時に適用されます。タグ変数を使用して、コンパートメントに作成されたリソースのタグのデフォルトを効率的に作成します。例:$(iam.principal.name}, $(iam.principal.type}, ${oci.datetime}
自由形式のタグ
リソースのライフ・サイクル中にリソースに適用されるユーザー定義の管理対象外メタデータ。