セキュリティ・サービス(Security Services)

Oracle Cloud Infrastructureリージョンは、インフラストラクチャの最上位コンポーネントです。各リージョンは地理的に分かれた領域であり、可用性ドメインと呼ばれるフォルト分離に対応する複数の区画が含まれます。可用性ドメインはリージョンのサブコンポーネントです。独立しており、高い信頼性があります。各可用性ドメインは、完全に独立したインフラストラクチャ(建物、発電機、冷房装置およびネットワーク接続)を使用して構築されています。物理的な分離によって、自然災害やその他の災害に対して保護することができます。

同じリージョン内の可用性ドメインは、安全で高速な低レイテンシ・ネットワークによって接続されます。これにより、アプリケーションのレイテンシやパフォーマンスへの影響を最小限に抑えながら、信頼性の高いアプリケーションやワークロードを構築および実行できます。可用性ドメイン間のリンクはすべて暗号化されます。

詳細は、リージョンおよび可用性ドメインを参照してください。

Oracle Cloud Infrastructureには、政府組織のセキュリティおよびコンプライアンス要件を満たす特定の特性を持つリージョンも用意されています。

• Oracle Cloud Infrastructure US Government Cloud
• Oracle Cloud Infrastructure United Kingdom Government Cloud

Oracle Cloud Infrastructure Identity and Access Managementサービスは、すべてのOracle Cloud Infrastructureリソースおよびサービスの認証および認可を提供します。様々な事業単位、チーム、個人によって共有される単一テナンシを使用する一方で、セキュリティ、分離およびガバナンスを維持することができます。

IAMでは、この項で説明するコンポーネントが使用されます。コンポーネントがどのように適合するかをより深く理解するには、シナリオ例を参照してください。

コンパートメント

関連するリソースの集まり。コンパートメントは、クラウド・リソースを編成および分離するためのOracle Cloud Infrastructureの基本コンポーネントです。使用と請求の測定、アクセス(ポリシーの使用による)、および分離(あるプロジェクトまたはビジネス・ユニットのリソースを別のプロジェクトまたはビジネス・ユニットと区別)のために、リソースを明確に区別するために使用できます。一般的な方法は、組織の主要部分ごとにコンパートメントを作成することです。詳細は、テナンシを設定するためのベスト・プラクティスについて学習を参照してください。

動的グループ

定義するルールに一致するリソース(コンピュート・インスタンスなど)を含む特別なタイプのグループ(このため、メンバーシップは、一致するリソースの作成または削除時に動的に変更される可能性があります)。これらのインスタンスは「プリンシパル」のアクターとして機能し、動的グループ向けに記述するポリシーに従ってサービスにAPIコールを行うことができます。

フェデレーション

管理者がアイデンティティ・プロバイダとサービス・プロバイダの間で構成する関係。Oracle Cloud Infrastructureをアイデンティティ・プロバイダとフェデレートする場合、アイデンティティ・プロバイダ内のユーザーとグループを管理します。Oracle Cloud InfrastructureのIAMサービスで認可を管理します。

グループ

同様のアクセス権限セットを共有するユーザーのコレクション。管理者は、テナンシ内のリソースを消費または管理できるようにグループを認可するアクセス・ポリシーを付与できます。同じグループのすべてのユーザーは、同じ権限セットを継承します。

ホーム・リージョン

IAMリソースが存在するリージョン。すべてのIAMリソースはグローバルで、すべてのリージョンで使用できますが、定義のマスター・セットは、単一のリージョンであるホーム・リージョンにあります。ホーム・リージョン内のIAMリソースを変更する必要があります。変更は、すべてのリージョンに自動的に伝播されます。詳細は、リージョンの管理を参照してください。

アイデンティティ・ドメイン

アイデンティティ・ドメインとは、ユーザーとロールの管理、ユーザーのフェデレートとプロビジョニング、Oracle Single Sign-On (SSO)構成を使用したセキュアなアプリケーション統合、およびOAuth管理を行うためのコンテナです。これは、Oracle Cloud Infrastructureのユーザー人口と、それに関連付けられた構成およびセキュリティ設定(MFAなど)を表します。

アイデンティティ・プロバイダ

フェデレーテッド・アイデンティティ・プロバイダとの信頼できる関係。Oracle Cloud Infrastructureコンソールに対して認証を試みるフェデレーテッド・ユーザーは、構成されているアイデンティティ・プロバイダにリダイレクトされます。正常に認証されると、フェデレーテッド・ユーザーはネイティブのIAMユーザーと同様にコンソールでOracle Cloud Infrastructureリソースを管理できます。

ムファ

マルチファクタ認証(MFA)は、ユーザーのアイデンティティを検証するために複数の要素を使用する必要がある認証方法です。

ネットワーク・ソース

テナンシ内のリソースへのアクセスが許可されたIPアドレスのグループ。IPアドレスは、パブリックIPアドレスか、テナンシ内のVCNからのIPアドレスです。ネットワーク・ソースの作成後、ネットワーク・ソース内のIPから発生したリクエストのみにアクセスを制限するポリシーを使用します。

リソース

Oracle Cloud Infrastructureサービスと対話する際に作成および使用するクラウド・オブジェクト。たとえば、コンピュート・インスタンス、ブロック・ストレージボリューム、仮想クラウド・ネットワーク(VCN)、サブネット、データベース、サードパーティ・アプリケーション、Software-as-a-Service (SaaS)アプリケーション、オンプレミス・ソフトウェアおよび小売Webアプリケーションです。

ロール

アイデンティティ・ドメイン内のユーザーに割り当てることができる一連の管理権限。

セキュリティ・ポリシー

どのユーザーがどのリソースにアクセスできるか、およびその方法を指定するドキュメントです。ポリシーを記述して、Oracle Cloud Infrastructure内のすべてのサービスへのアクセスを制御できます。アクセス権はグループ・レベルおよびコンパートメント・レベルで付与されます。つまり、特定のコンパートメント内またはテナンシ自体への特定のアクセスのタイプをグループに付与するポリシーを記述できます。テナンシへのグループ・アクセス権を付与する場合、グループはテナンシ内のすべてのコンパートメントへの同じアクセスのタイプを自動的に取得します。詳細は、シナリオ例とポリシーの仕組みを参照してください。「ポリシー」の用法は様々です。ポリシー言語で記述された個々のステートメントを意味する場合、"policy"という名前の(Oracle Cloud ID (OCID)が割り当てられている)単一ドキュメント内のステートメントの集合を意味する場合、リソースへのアクセスを制御するために組織で使用されるポリシーの本文全体を意味する場合があります。

ポリシーを適用すると、ポリシーが有効になるまでに若干の遅延が発生する可能性があります。

サインオン・ポリシー

サインオン・ポリシーを使用すると、アイデンティティ・ドメイン管理者、セキュリティ管理者およびアプリケーション管理者は、ユーザーにアイデンティティ・ドメインへのサインインを許可するかどうかを決定する基準を定義できます。

タグ

タグを使用すると、レポートまたは一括処理のために、複数のコンパートメントにまたがるリソースを整理できます。

テナント

組織のOracle Cloud Infrastructureリソースすべてを含むルート・コンパートメント。Oracleによって、会社のテナンシが自動的に作成されます。テナンシの中に、IAMエンティティ(ユーザー、グループ、コンパートメントおよびいくつかのポリシー)があります。また、テナンシ内のコンパートメントにポリシーを入れることもできます。作成するコンパートメント内に他のタイプのクラウド・リソース(インスタンス、仮想ネットワーク、ブロック・ストレージ・ボリュームなど)を配置します。

テナンシ管理者は、ユーザーとグループを作成し、コンパートメントにパーティション化されるリソースへのアクセス権を最小限に抑えることができます。

ユーザー

会社のOracle Cloud Infrastructureリソースを管理または使用する必要がある個々の従業員またはシステム。ユーザーには、インスタンスの起動、リモート・ディスクの管理、仮想クラウド・ネットワークの使用などが必要な場合があります。アプリケーションのエンド・ユーザーは、通常、IAMユーザーではありません。ユーザーには1つ以上のIAM資格証明があります(ユーザー資格証明を参照)。

Allow group <group_name> to <verb> <resource-type> in compartment <compartment_name>

Allow group GroupAdmins to manage groups in tenancy

Allow group TestNetworkAdmins to manage virtual-network-family in compartment TestCompartment

詳細は、次を参照してください:

• IAMの概要
• IAMアイデンティティ・ドメインのタイプ
• アイデンティティ・ドメインの管理
• コンパートメントの管理
• ポリシーの仕組み
• ユーザー資格証明
• アイデンティティ・プロバイダによるフェデレート
• IAMの保護

クラウド・ガードを使用して、構成に関連するセキュリティの弱点がOracle Cloud Infrastructureリソースにないかを調べたり、オペレータやユーザーにリスクのあるアクティビティがないかを調べたりします。検出時に、Cloud Guardは修正処理を提案し、特定の処理を自動的に実行するように構成できます。例:

• パブリックにアクセス可能なインスタンス(パブリックIPアドレスまたはパブリック・サブネット上にある)を検出し、インスタンスを停止します。
• パブリックにアクセス可能なオブジェクト・ストレージバケットを検出し、バケットを無効にします。
• 疑わしいIPアドレスからのユーザー・ログインを検出し、このアドレスからのトラフィックを制限します。
• 侵害されたアカウントまたは内部脅威を示す可能性のあるユーザー・アクティビティを検出します。

Oracleでは、テナンシでCloud Guardを有効にすることをお薦めします。テナンシ全体(ルート・コンパートメントおよびすべてのサブコンパートメント)を調べるようにクラウド・ガード・ターゲットを構成することも、特定のコンパートメントのみをチェックするようにターゲットを構成することもできます。

各ターゲットはディテクタ・レシピに関連付けられており、クラウド・ガードに問題をレポートさせる特定のユーザー・アクションまたはリソース構成を定義します。Oracleには、デフォルトのクラウド・ガード・ディテクタ・レシピがいくつか用意されています。これらはそのまま使用することも、必要に応じてカスタマイズすることもできます。たとえば、特定のディテクタ・ルールに関連付けられたリスク・レベルや設定を変更できます。クラウド・ガードで新しいディテクタ・ルールが追加されると、Oracle管理レシピで自動的に有効になり、カスタム・レシピで無効になります。

クラウド・ガードの脅威ディテクタ・レシピには、最終的にセキュリティの問題を引き起こす可能性のあるテナンシ内のアクティビティの不足パターンを検出するために特別に設計された一連のルールが含まれています。

Cloud Guardレスポンダ・レシピは、ディテクタが特定した問題に対応するために実行するアクションまたはアクションのセットを定義します。また、イベントおよび通知サービスを使用して、Cloud Guardが通知対象の問題のタイプを検出するたびに通知を送信することもできます。通知は、電子メールまたはSlackを介して送信することも、関数サービスでカスタム・コードを実行することもできます。

For more information, see Cloud Guard.

Oracle Cloud Infrastructure Vulnerability Scanning Serviceは、コンピュート・インスタンスおよびコンテナ・イメージに潜在的な脆弱性がないかを定期的にチェックすることで、セキュリティ状態を改善するのに役立ちます。このサービスは、これらの脆弱性に関するメトリックおよび詳細を含むレポートを生成し、それぞれにリスク・レベルを割り当てます。例:

• 意図せずに開いたままになっているポートは、クラウド・リソースに対する潜在的な攻撃ベクトルであるか、ハッカーが他の脆弱性を悪用できる可能性があります。
• 脆弱性に対処するために更新およびパッチが必要なOSパッケージ
• ハッカーが悪用する可能性のあるOS構成
• ターゲットOSのCenter for Internet Security (CIS)によって公開されている業界標準のベンチマーク

Cloud Guardでこれらの脆弱性を監視することもできます。脆弱性が検出されると、Cloud Guardは修正処理を提案し、特定の処理を自動的に実行するように構成できます。

詳細は、Scanning Overviewを参照してください。

セキュリティ・ゾーンを使用すると、コンピュート、ネットワーキング、オブジェクト・ストレージ、データベースおよびその他のリソースがOracleのセキュリティ原則およびベスト・プラクティスに準拠していることを確認できます。セキュリティ・ゾーンは、1つ以上のコンパートメントおよびセキュリティ・ゾーン・レシピに関連付けられます。セキュリティ・ゾーンでリソースを作成および更新すると、Oracle Cloud Infrastructureでは、ゾーン・レシピのセキュリティ・ゾーン・ポリシーに対してこれらの操作が検証されます。セキュリティ・ゾーン・ポリシーに違反している場合、操作は拒否されます。

次に、セキュリティ・ゾーン・ポリシーの例を示します:

• セキュリティ・ゾーンのサブネットをパブリックにすることはできません。すべてのサブネットはプライベートである必要があります。
• セキュリティ・ゾーン内のコンピュート・インスタンスのブート・ボリュームもセキュリティ・ゾーン内に存在する必要があります。
• セキュリティ・ゾーンのオブジェクト・ストレージ・バケットは、顧客管理のマスター暗号化キーを使用する必要があります。
• 特定のリソース(ブロック・ボリュームやコンピュート・インスタンスなど)をセキュリティ・ゾーンから標準コンパートメントに移動することができません。

セキュリティ・ゾーンを作成する前に、クラウド・ガードを有効にする必要があります。クラウド・ガードは、セキュリティ・ゾーンの前に作成された既存のリソースのポリシー違反を検出するのに役立ちます。

詳細は、セキュリティ・ゾーンの概要を参照してください。

ボールト・サービスを使用すると、次のリソースを作成および管理できます:

• ボールト
• KEYS
• シークレット

ボールトには、データの保護や保護されたリソースへの接続に使用する、暗号化キーおよびシークレット資格証明が含まれます。顧客管理リソースとして、ボールト、キーおよびシークレットのアクセス権を誰が持つかを完全に制御できます。また、認可されたユーザーやサービスがボールト・リソースに対して何を実行できるかも制御します。アクセスのレベルは幅広く、特定のサービスが個々のキーを使用できるかどうかといった細かいものから、ユーザーがボールトからキーを削除してキーの使用を完全に禁止できるかどうかといった大きな影響を持つライフサイクル管理アクティビティまで多様です。

キーは、連邦情報処理標準(FIPS) 140-2セキュリティ・レベル3のセキュリティ証明を満たす、可用性の高い永続的なハードウェア・セキュリティ・モジュール(HSM)に格納されます。シークレットおよびシークレット・バージョンは、base64でエンコードされ、マスター暗号化キーを使用して暗号化されますが、HSM内には存在しません。

Vaultサービスでサポートされている主な暗号化アルゴリズムには、Advanced Encryption Standard (AES )、Rivest - Shamir - Adleman (RSA)アルゴリズム、楕円曲線デジタル署名アルゴリズム(ECDSA)などがあります。AES対称キーおよびRSA非対称キーを作成して、暗号化および復号化に使用できます。RSAまたはECDSA非対称キーを使用してデジタル・メッセージに署名することもできます。

セキュリティ・ゾーン・ポリシーでは、可能な場合、顧客管理キーを使用してリソースを暗号化する必要があります。次のサービスでは、リソース暗号化で顧客管理キーの使用がサポートされています:

• ブロック・ボリューム
• Container Engine for Kubernetes
• Oracle Cloud Infrastructure Database
• ファイル・ストレージ
• オブジェクト・ストレージ
• ストリーミング

詳細は、ボールトの概要を参照してください。

セキュリティ・アドバイザは、Oracleのセキュリティ原則およびベスト・プラクティスに適合するクラウド・リソースの作成に役立ちます。また、リソースがセキュリティ・ゾーン・ポリシーによって適用される要件を満たしていることも確認されます。たとえば、Vaultサービスを使用して、顧客管理のマスター暗号化キーで暗号化されたリソースをすばやく作成できます。

たとえば、セキュリティ・アドバイザを使用すると、次のリソースを作成できます:

• オブジェクト・ストレージ・ バケット 
• ファイル・ストレージ・ファイル・システム 
• コンピュート・インスタンス(コンピュート) (および関連するブート・ボリューム)
• ブロック・ボリューム・ブロック・ストレージ・ ボリューム 

詳細は、セキュリティ・アドバイザの概要を参照してください。

Oracle Cloud Infrastructure Bastionでは、パブリック・エンドポイントを持たないターゲット・リソースへのアクセスが制限され、時間が制限されます。

要塞の構成を通じて、Secure Shell (SSH)セッションを介して、認可されたユーザーがプライベート・エンドポイントのターゲット・リソースに接続できます。接続したユーザーは、SSHでサポートされている任意のソフトウェアまたはプロトコルを使用してターゲット・リソースとやり取りできます。たとえば、Remote Desktop Protocol (RDP)コマンドを発行したり、Oracle Net Servicesを使用してデータベースに接続したりできます。ターゲットには、コンピュート・・インスタンス、DBシステム、Autonomous Database for Transaction Processingおよび混合ワークロード・データベースなどのリソースを含めることができます。

ベースはパブリック・サブネットに存在し、ユーザーをプライベート・サブネット内のターゲット・リソースに接続するために必要なネットワーク・インフラストラクチャを確立します。IAMサービスとの統合により、ユーザー認証および認可が提供されます。要塞では、要塞によってホストされるセッションに接続できるIPアドレスを指定することで、追加のセキュリティ・レイヤーが提供されます。

詳細は、要塞を参照してください。

Oracle Cloud Infrastructure Threat Intelligenceは、多数の異なるソース間で脅威インテリジェンス・データを集計し、このデータをキュレーションして、Oracle Cloud Guardやその他のOracle Cloud Infrastructureサービスで脅威の検出と予防のための実用的なガイダンスを提供します。

悪意のあるアクターは、多くの場合、既知の手法を使用してターゲット環境を攻撃します。環境に見られる脅威インジケータのコンテキスト情報は、アラートの優先順位を決定し、脅威の展望を理解するのに役立ちます。脅威インテリジェンスは、Oracleの優秀なセキュリティ研究者、独自のテレメトリ、業界標準のオープン・ソース・フィードおよびサードパーティ・パートナからのインサイトを提供します。

脅威ディテクタ・レシピがクラウド・ガードで有効化されている場合、脅威インテリジェンスのデータと監査のログおよびテレメトリを比較して、疑わしいアクティビティを検出し、問題としてレポートします。

詳細は、「脅威インテリジェンスの概要」を参照してください。

Oracle Cloud Infrastructure Web Application Firewall (WAF)は、悪意のある好ましくないインターネット・トラフィックからアプリケーションを保護する、Payment Card Industry (PCI)に準拠したクラウドベースのセキュリティ・サービスです。WAFは、インターネットに直接接続されているエンドポイントを保護することにより、アプリケーション全体に一貫性のあるルールを適用できます。

クロスサイト・スクリプティング(XSS)やSQLインジェクション、OWASPが定義したその他の脆弱性を含むインターネットの脅威に対して保護ルールを作成および管理するには、WAFを使用します。必要なボットが入ることは許可しながら、不要なボットを減らすことができます。ModSecurity Rule Languageを使用して、カスタム保護ルールを定義し、WAF構成に適用することもできます。

WAFを使用して、様々な条件を満たすリクエストに対して明示的なアクションを定義するアクセス・ルールを作成します。たとえば、アクセス・ルールでは、地理情報またはリクエストの署名に基づいてリクエストを制限できます。条件に一致するすべてのリクエストのCAPTCHAをログに記録して許可、検出、ブロック、リダイレクト、バイパスまたは表示するようにルール・アクションを設定できます。

詳細は、Web Application Firewallの概要を参照してください。

Oracle Cloud Infrastructure Auditサービスでは、顧客のテナンシ内のリソースへのすべてのAPIコールと、コンソールからのログイン・アクティビティが記録されます。監査サービスを使用してテナンシ内のすべてのユーザー・アクティビティをモニターすることで、セキュリティおよびコンプライアンスの目標を達成できます。コンソール、SDKおよびコマンドライン(CLI)のコールはすべてAPIを経由するため、これらのソースからのすべてのアクティビティが含まれます。監査レコードは、認証済でフィルタ可能な問合せAPIから利用できます。または、Oracle Cloud Infrastructure Object Storageからバッチ・ファイルとして取得できます。監査ログの内容には、発生したアクティビティ、アクティビティを開始したユーザー、リクエストの日時、リクエストのソースIP、ユーザー・エージェントおよびHTTPヘッダーが含まれます。

詳細は、監査の概要を参照してください。