機械翻訳について

1 Oracle Private Cloud Applianceセキュリティの概要

Oracle Private Cloud Applianceは、顧客ベースのハードウェアと事前ロードされたソフトウェアを、顧客データ・センターとオンプレミス・ネットワーク内で完全に実行されるクラウド・コンポーネントと組み合せたエンジニアド・システムです。 Oracle Cloud Infrastructureアカウントは関係ありませんが、Oracle Private Cloud ApplianceはコアOracle Cloud Infrastructureサービスを提供し、コンピュート、ネットワーク、ブロック・ボリューム・ストレージオブジェクト・ストレージファイル・システム・ストレージIdentity and Access ManagementなどのOracle Cloud Infrastructureサービスと完全に互換性があり、その他小さい要素または少ない可視要素もあります。 Oracle Private Cloud Applianceは切断されているため、「サービス・エンクレーブ」と呼ばれる独自のコントロール・プレーン実装もあります。

このエンジニアド・システムは、ローカル・プラクティスに依存しないレベルのセキュリティを提供するOracleによってインストールされます。 ただし、システム管理者は、セキュリティ・ベースラインとして提供されるものを正確に理解する必要があります。 その後、管理者はセキュリティ・プラクティスと構成を調整して、特定の状況に必要なセキュリティ・レベルを実現できます。

製品セキュリティの概要

製品セキュリティの概要

Oracle Private Cloud Applianceのコア・セキュリティ・コンポーネントは階層化されます。 Oracle Private Cloud Applianceの3つのレイヤーは次のとおりです:

  • インフラストラクチャ - これは、お客様の施設に取り付けられている物理ラック・ハードウェアです。 セキュリティ関連のタスクの中には、システムのインストール時にこの基本レベルで実行されるものがあります。

  • 「サービス・エンクレーブ」 - これは、アプライアンス・インフラストラクチャが制御されるシステムの一部です。 このエンクレーブへのアクセスは厳密に監視され、特権管理者に制限されています。 「サービス・エンクレーブ」は3つの管理ノードのクラスタで実行され、多くのセキュリティ関連タスクがこのレベルで実行されます。

  • 「コンピュート・エンクレーブ」 - Oracle Cloud Infrastructureとの互換性のために設計された「コンピュート・エンクレーブ」は、ワークロードがユーザーまたはグループによって作成、構成およびホストされ、コンピュート・インスタンス、ネットワーク、ストレージなどのクラウド・リソースが制御される場所です。

Oracle Private Cloud Applianceは、他のOracle Oracle製品と同じ基本的なセキュリティ原則に従います。 次の原則があります:

  • 認証: 認証は、通常、ユーザー名とパスワード、共有キーなどの機密情報を使用して行われるユーザーの識別方法です。 すべてのコンポーネントは、認証を使用してユーザーの本人確認を行います。 デフォルトでは、ローカル・ユーザー名とパスワードが認証に使用されます。 共有キー・ベースの認証も可能です。

  • 承認: 管理者は、リソースに対するユーザーまたはグループ権限を、リソースに許可されるアクセス・レベルとともに構成します。 人事は、与えられたアクセス・レベルのリソースにのみアクセスできます。 管理権限を持つユーザーは、リソース(すべてのリソース、インスタンス・ファミリなど)への1つ以上のアクセス・タイプ(検査、読取り、使用、管理)を持つユーザーおよびグループを認可できます。

  • 監査: 監査では、Oracle Private Cloud Applianceの様々なレイヤーでユーザー・アクティビティのレコードが保持されます。 監査レコードは、「サービス・エンクレーブ」「コンピュート・エンクレーブ」およびインフラストラクチャに対して存在します。 管理者は、監査レコードを使用して、特定のユーザーをシステム内の1つ以上のコンポーネントで発生した変更に関連付けることができます。 監査レコードをモニターして、レイヤー内のユーザーがコンポーネントに正しくアクセスして使用していることを確認し、ユーザーのリソース権限が過度または不足していることを確認します。 監査レコードでは、サービス拒否の試行、境界の攻撃の調査によるサービスへのアクセスの試み、またはデータ損失や予期しないリソース変更の原因となったリソースの誤用を識別する、予期しないシステム使用パターンを識別することもできます。

  • 会計: 会計を使用すると、管理者はハードウェアおよびクラウド・リソースの在庫を追跡できます。 ハードウェア・アセットはシリアル番号で追跡されますが、クラウド・リソースはOracle Cloud ID (OCID)で追跡されます。 ハードウェア・コンポーネントの場合、Oracleパーツ番号はすべてのカード、モジュール、およびマザーボードに電子的に記録されます。 これらは、インベントリまたはOracleにレポートされた問題との関連付けに使用できます。 OCIDsで追跡されるクラウド・リソースを管理者が監視して、使用状況およびリソースの消費を追跡できます。

上記のセキュリティ原則が適切に適用されると、次のことが可能になります:
  • ミッション・クリティカルなワークロードの生存率 - Oracle Private Cloud Applianceは、内部ユーザーまたは外部の当事者が行う偶発的および悪意のあるアクションによる損害を防止または最小化します。 これは、コンポーネントのセキュリティ・テスト、プロトコルの脆弱性のチェック、およびセキュリティ違反中でもソフトウェアの継続性の検証によって実現されます。

  • オペレーティング環境を保護するための多層防御 - Oracle Private Cloud Applianceは、複数の独立した相互強制的なセキュリティ制御を採用し、組織がワークロードとデータに対して安全なオペレーティング環境を構築するのに役立ちます。 システムのすべてのレベルは、一連のセキュリティ機能によって保護されます。

  • サービスおよびユーザーの最低権限アクセス - Oracle Private Cloud Applianceは、アプリケーション、サービスおよびユーザーがタスクを実行するために必要な機能にアクセスできるようにするセキュリティ・ポリシーの使用を促進します。 ただし、不要な機能、サービスおよびインタフェースへのアクセスを制限することが、同様に重要です。 ユーザーおよび管理者は、特定の懸念領域に限定されます。

  • イベントおよびアクションの説明責任 - Oracle Private Cloud Applianceは、各レイヤーの詳細な監査証跡と、リソースの説明に役立つコントロールを提供します。 これにより、管理者は、発生したインシデント(サービス拒否攻撃など)を検出してレポートしたり、予防可能でないインシデント(監査ログから結果として発生したリソースの変更までトレーサビリティを介して)発生した後でレポートできます。

  • オペレーティング・システムのセキュリティの理解 - オペレーティング・システムには、常にオペレーティング・システムの整合性を確保するために、パッチおよび更新中に厳密なセキュリティが必要です。 これは、セキュリティ・ポリシーを適用し、ネットワーク・アクセスを制限し、すべてのオペレーティング・システム・レベルのアクティビティをモニターすることによって可能です。

セキュリティ計画

新しいソフトウェア機能やパラメータ調整のような製品にはセキュリティを追加できません。

この初期の製品インストール計画で考慮するカテゴリおよび例を次に示します:

  • ネットワーク: 仮想インタフェースおよび物理インタフェース、ブリッジおよびルーティング

  • ユーザー・アクセス: ユーザーとグループ、そのロール、および検査、読み取り、使用、または管理するためにアクセスするリソース

  • パスワード・ルール: 長さと文字の要件、その他の特性

  • 暗号化アルゴリズム: 使用ガイドラインの許可または義務付け

  • プロセス・セキュリティのパッチ適用または更新: 制限、プロシージャの実行が許可されているロール

これは完全なリストではありません。 前もって計画できることが多いほど、よい。

セキュリティの基本的な考慮事項

これらの原則は、製品の保護に不可欠です:

  • ソフトウェアを最新の状態に維持します。 これには最新の製品リリースと、適用されるすべてのパッチが含まれます。 詳細は、「Oracle Private Cloud Applianceインストレーション・ガイド」および「Oracle Private Cloud Applianceパッチ適用ガイド」を参照してください。

  • 権限を制限します(可能な場合)。 自分の作業を行うために必要なアクセス権のみをユーザーに付与します。 ユーザー権限を定期的にレビューして、現在の作業要件に対する関連性を判断します。 詳細は、「Oracle Private Cloud Appliance概要ガイド」を参照してください。

  • システムアクティビティをモニターします。 どのシステム・コンポーネントにアクセスできるユーザーとその頻度を確認し、それらのコンポーネントをモニターします。

  • Oracleセキュリティ機能について学習し、使用します。

  • セキュリティのベスト・プラクティスを使用します。

顧客セキュリティの責任

お客様は、お客様が直接管理するシステムの側面を常に保護する責任を負います。 次の職責があります:

  • 情報とデータ: 顧客は、常に情報とデータの制御を維持します。 顧客は、このデータの使用方法とタイミングを制御します。 クラウド・プロバイダ(Oracle)は顧客データに対する可視性をゼロにし、すべてのデータ・アクセスは設計によって顧客に制御されます。

  • アプリケーション・ロジックおよびコード: クラウド・リソースのスピン・アップに関係なく、顧客はアプリケーションのライフ・サイクル全体で顧客独自のアプリケーションを保護および制御します。 これには、悪意のある誤用や侵入からのコード・リポジトリの保護、開発と統合プロセス中のアプリケーション・ビルド・テスト、安全な本番アクセスの保証、接続されたシステムのセキュリティの維持が含まれます。

  • アイデンティティおよびアクセス: お客様は、アイデンティティおよびアクセス管理(IAM)のすべての側面について常に責任を負います。 これには、認証および認可メカニズム、シングル・サインオン(SSO)アクセス、マルチ・ファクタ認証(MFA)、アクセス・キー、証明書、ユーザー作成プロセスおよびパスワード管理が含まれます。

  • プラットフォームおよびリソース構成: クラウド環境がスピン・アップすると、顧客はオペレーティング環境を制御します。 これらの環境に対する制御の維持方法は、インスタンスがサーバー・ベースかサーバーレスか(PaaS)かに応じて異なります。 サーバー・ベースのインスタンスでは、OSやアプリケーションのハードニング、OSやアプリケーション・パッチのメンテナンスなど、セキュリティをより実践的に制御する必要があります。 クラウド内のサーバー・ベースのインスタンスは物理サーバーのように動作し、顧客データ・センターの拡張として機能します。 サーバーレス・リソースの場合、プロバイダのコントロール・プレーンは、構成の設定に対するアクセス権を顧客に付与します。 どのような場合においても、安全な方法で顧客インスタンスを構成する方法をお客様に知る責任はお客様にあります。

    さらに、お客様は、クラウドに接続する顧客組織のすべてを保護する責任も負います。 次のものが含まれます。
    • オンプレミス・インフラストラクチャ・スタックおよびユーザー・デバイス。

    • 顧客が所有するネットワークおよびアプリケーション。

    • 内部と外部の両方のユーザーをクラウドおよび相互に接続する通信レイヤー。

    また、お客様は、お客様の管理下にあるドメインのセキュリティの脅威、インシデント、およびレスポンスをモニタリングおよびアラートする必要があります。

監査に関するノート

監査を適切に実施するには、職務を確実に分離する必要があります。 この分離により、変更の問題が原因で問題が発生した場合に、次のことを判断しやすくなります:
  • だれが変更を行いましたか? ("root"が改変したという情報以上の。)

  • 変更はいつ行われましたか? (適切なログ保持期間が重要です。)

  • 変更の目的は何でしたか? (悪質でない場合は、理由により変更されました。)

監査プロセスの主なポイントは、担当者が必要な変更をより適切に実装するために前進できるようにすることです。