このページは機械翻訳したものです。

Oracle Cloud Infrastructureドキュメント
Free Tierを試してみる

オブジェクト・ストレージの保護

このトピックでは、オブジェクト・ストレージのセキュリティ情報および推奨事項について説明します。

オブジェクト・ストレージ・サービスは、信頼性とコスト効率の高いデータ耐久性を実現する高パフォーマンス・ストレージ・プラットフォームです。分析データ、リッチ・コンテンツ(イメージやビデオなど)を含む、あらゆるコンテンツ・タイプの非構造化データを無制限に格納できます。

セキュリティの責任

Object Storageを安全に使用するには、セキュリティおよびコンプライアンスの責任について学んでください。

通常、Oracleはクラウド・インフラストラクチャおよび操作のセキュリティ(クラウド・オペレータのアクセス制御やインフラストラクチャ・セキュリティ・パッチ適用など)を提供します。クラウド・リソースをセキュアに構成する責任はユーザーにあります。クラウドのセキュリティは、ユーザーとOracleの共同責任です。

Oracleは、次のセキュリティ要件に対して責任を負います:

  • 物理セキュリティ: Oracleは、Oracle Cloud Infrastructureで提供されるすべてのサービスを実行するグローバル・インフラストラクチャを保護する責任を負います。このインフラストラクチャは、Oracle Cloud Infrastructureサービスを実行するハードウェア、ソフトウェア、ネットワーキングおよび設備で構成されます。

お客様のセキュリティの責任についてこのページで説明します。次のような領域があります:

  • アクセス制御: 可能なかぎり権限を制限します。ユーザーが作業を行うために必要なアクセス権のみを付与する必要があります。
  • 暗号化と機密性:暗号化キーおよびシークレットを使用して、データを保護し、保護されたリソースに接続します。これらのキーを定期的にローテーションします。

初期セキュリティ・タスク

このチェックリストを使用して、新しいOracle Cloud InfrastructureテナンシでObject Storageを保護するために実行するタスクを識別します。

タスク 詳細情報
IAMポリシーを使用したユーザーおよびリソースへのアクセス権の付与 IAMポリシー
カスタム・キーを使用したリソースの暗号化 データ暗号化
リソースへのネットワーク・アクセスの保護 ネットワーク・セキュリティ
クラウド・ガードの有効化および構成(オプション) クラウド・ガード
セキュリティ・ゾーンの作成(オプション) セキュリティ・ゾーン

定期的なセキュリティ・タスク

Object Storageの開始後、このチェックリストを使用して、定期的に実行することが推奨されるセキュリティ・タスクを識別します。

タスク 詳細情報
暗号化キーのローテーション データ暗号化
クラウド・ガードで検出された問題への対応 クラウド・ガード
定期的にバックアップを実行します データ耐久性
データの異なる場所への移動またはコピー時の整合性の確保 データ・セキュリティのチェックサム
セキュリティ監査を実行します 監査

IAMポリシー

オブジェクト・ストレージへのアクセスを制限するには、ポリシーを使用します。

ポリシーは、Oracle Cloud Infrastructureリソースに誰がどのようにアクセスできるかを指定します。詳細は、ポリシーの仕組みを参照してください。

グループに、その職責を実行するために必要な最小限の権限を割り当てます。各ポリシーには、グループに許可されるアクションを記述する動詞があります。使用可能な動詞は、アクセス・レベルが低い方から順にinspect、read、use、manageです。

object-familyのリソース・タイプ(バケットとオブジェクト)への最小のアクセス権限を割り当てます。たとえば、inspect動詞では、バケットが存在するかどうかを確認し(HeadBucket)、コンパートメント内のバケットをリスト(ListBucket)できます。manage動詞では、リソースに対するすべての権限が付与されます。

IAMユーザーおよびグループの最小セットにDELETE権限を付与することをお薦めします。この演習では、認可されたユーザーまたは悪意のあるアクターによる不注意な削除によるデータの損失を最小限に抑えます。DELETE権限はテナンシ管理者にのみ付与します。

次の例で、ポリシーの対象範囲はテナンシです。ただし、コンパートメント名を指定することによって、テナンシ内の特定のコンパートメントに対象範囲を絞り込むことができます。

オブジェクト・ストレージ・ポリシーの詳細およびその他の例を表示するには、オブジェクト・ストレージ、アーカイブ・ストレージおよびデータ転送の詳細を参照してください。

アクセス制御

IAMポリシーの作成に加えて、事前認証済リクエストなどの機能を使用して、Object Storageへのアクセスをロックダウンします。

パブリック・バケット

パブリック・バケットでは、認証されていない読取りや匿名の読取りがバケット内のすべてのオブジェクトに対して許可されます。パブリック・バケットを有効にする前に、計画しているパブリック・バケットのユースケースを慎重に評価してください。

IAM資格証明のないユーザーにバケットまたはオブジェクトへのアクセス権を付与するには、事前認証済リクエストを使用することをお薦めします。デフォルトでは、バケットはパブリック・アクセスなしで作成されます(アクセス・タイプはNoPublicAccessに設定されます)。

既存のバケットのアクセス・タイプをObjectReadまたはObjectReadWithoutListに更新すると、バケットをパブリックにすることができます。意図せずにまたは悪意のある方法で既存のバケットがパブリックにされる可能性を最小限に抑えるため、BUCKET_UPDATE権限を最小限のIAMグループに限定します。

次のCLIコマンドは、バケットに割り当てられたpublic-access-typeを戻します。

oci os bucket get -ns <your_namespace> --bucket-name <bucket_name> | grep "public-access-type"

属性public-access-typeの値がNoPublicAccessの場合、バケットはprivateです。ObjectReadなどの他の値は、パブリック・バケットを示します。

事前認証済リクエスト

IAM資格証明がないユーザーの場合は、事前認証済リクエスト(PAR)を使用して、オブジェクトまたはバケットの期限付きアクセス権を付与することをお薦めします。

事前認証済リクエストでは、オブジェクトにアクセスするための適切な権限を持つIAMユーザーが、これらのオブジェクトへの時間制限アクセスを付与する特別なURLを作成できます。詳細は、事前認証済リクエストの使用を参照してください。

事前認証済リクエストの作成者は、PAR_MANAGE権限と、付与するアクセス・タイプに対する適切なIAM権限を持っている必要があります。次のいずれかに対する読取り、書込みまたは読取り/書込みアクセス権を付与する事前認証済リクエストを作成できます:

  • バケット内のすべてのオブジェクト。
  • バケット内の特定のオブジェクト。
  • 指定された接頭辞を持つバケット内のすべてのオブジェクト。

複数のオブジェクトに適用されるリクエストの場合、ユーザーにそれらのオブジェクトのリスト表示を許可するかどうかを決定することもできます。

バケットへの事前認証済リクエスト・アクセスは、監査ログで署名されます。オブジェクトへの事前認証済リクエスト・アクセスは、サービス・ログに記録されます。

重要

事前認証済リクエストを作成する際にシステムによって提供される一意のURLは、ユーザーがリクエスト・ターゲットにアクセスできる唯一の方法です。URLを耐久ストレージにコピーします。URLは作成時にのみ表示され、オブジェクト・ストレージに格納されておらず、後で取得することはできません。

次のCLIコマンドは、バケット内のオブジェクトPARのリストを戻します。

oci os preauth-request list -ns <your_namespace> -bn <bucket_name>

クラウド・ガード

クラウド・ガードを有効にして使用し、オブジェクト・ストレージのセキュリティ問題を検出して対応します。

問題を検出すると、クラウド・ガードは修正アクションを提案します。特定のアクションを自動的に実行するようにクラウド・ガードを構成することもできます。クラウド・ガードには、オブジェクト・ストレージに対する次のディテクタ・ルールが含まれています。

  • バケットがパブリックです
  • オブジェクト・ストレージ・バケットがOracle管理キーで暗号化されています
  • IAM顧客キーが作成されました

クラウド・ガードで使用可能なすべてのディテクタ・ルールのリストは、ディテクタ・レシピ・リファレンスを参照してください。

まだ行っていない場合は、クラウド・ガードを有効にし、リソースを含むコンパートメントを監視するように構成します。クラウド・ガード・ターゲットを構成して、テナンシ全体(ルート・コンパートメントおよびすべてのサブコンパートメント)を調査するか、特定のコンパートメントのみをチェックできます。クラウド・ガードの開始を参照してください。

クラウド・ガードを有効にすると、検出されたセキュリティの問題を表示して解決できます。「報告された問題の処理」を参照してください。

セキュリティ・ゾーン

セキュリティ・ゾーンを使用すると、オブジェクト・ストレージ内のリソースがセキュリティのベスト・プラクティスに準拠していることが保証されます。

セキュリティ・ゾーンは、1つ以上のコンパートメントおよびセキュリティ・ゾーン・レシピに関連付けられます。セキュリティ・ゾーンのコンパートメントでリソースを作成および更新すると、Oracle Cloud Infrastructureでは、これらの操作がレシピのセキュリティ・ゾーン・ポリシーのリストに対して検証されます。レシピ内のポリシーに違反している場合、操作は拒否されます。オブジェクト・ストレージのリソースには、次のセキュリティ・ゾーン・ポリシーを使用できます。

  • deny public_buckets
  • deny buckets_without_vault_key

すべてのセキュリティ・ゾーン・ポリシーのリストは、セキュリティ・ゾーン・ポリシーを参照してください。

既存のリソースをセキュリティ・ゾーン内のコンパートメントに移動するには、リソースがゾーンのレシピ内のすべてのセキュリティ・ゾーン・ポリシーに準拠している必要があります。同様に、セキュリティ・ゾーン内のリソースはセキュリティ・ゾーンの外部のコンパートメントに移動できません。移動するとセキュリティが低下する可能性があるためです。「セキュリティ・ゾーンの管理」を参照してください。

データ暗号化

Vaultサービスで暗号化キーを作成およびローテーションし、オブジェクト・ストレージのリソースを保護します。

オブジェクト・ストレージのすべてのデータは、保存中にAES-256を使用して暗号化されます。暗号化はデフォルトでオンになっており、オフにすることはできません。各オブジェクトは暗号化キーを使用して暗号化され、オブジェクト暗号化キーはマスター暗号化キーを使用して暗号化されます。

ボールトは、データの保護に使用する暗号化キーを格納する論理エンティティです。保護モードに応じて、キーはサーバーに格納されるか、高可用性および耐久性のあるハードウェア・セキュリティ・モジュール(HSM)に格納されます。当社のHSMは、連邦情報処理標準(FIPS) 140-2セキュリティ・レベル3のセキュリティ認証を満たしています。ボールトの管理およびキーの管理を参照してください。

デフォルトの暗号化キーは、特定のOracle Cloud Infrastructureリソースの作成時に自動的に生成できますが、Vaultサービスで独自のカスタム暗号化キーを作成および管理することをお薦めします。

カスタム暗号化キーを新しいバケットまたは既存のバケットに割り当てるには、次を参照してください:

各マスター暗号化キーには、キー・バージョンが自動的に割り当てられます。キーをローテーションすると、ボールト・サービスにより新しいキー・バージョンが生成されます。定期的にキーをローテーションすると、1つのキー・バージョンによって暗号化または署名されるデータの量が制限されます。キーが構成されたことがある場合、キーのローテーションによってデータのリスクが軽減されます。キーの管理を参照してください。

IAMポリシーを使用して、暗号化キーの作成、ローテーションおよび削除を厳密に制限することをお薦めします。Vaultサービスの詳細を参照してください。

また、オブジェクト・ストレージ・バケットに格納する前に、クライアント側暗号化を使用してオブジェクトを暗号化キーで暗号化することもできます。お客様が利用できるオプションは、Amazon S3 Compatibility APIと、AWS SDK for Javaで使用可能なクライアント側のオブジェクト暗号化サポートを使用することです。このSDKの詳細は、Amazon S3互換API を参照してください。

データ耐久性

Object Storageでデータの定期的なバックアップを実行します。

未認可のユーザーによる意図しない削除や悪意のある削除によるデータ損失を最小限に抑えます。次をお薦めします:
  • オブジェクト・バージョニングを使用して、新しいオブジェクトのアップロード、既存のオブジェクトの上書き、またはオブジェクトの削除のたびに、オブジェクト・バージョンを自動的に作成します。
  • BUCKET_DELETE権限およびOBJECT_DELETE権限は、IAMの最小限のユーザーとグループに付与します。削除権限を付与できるのは、テナンシ管理者とコンパートメント管理者のみです。

"Write once、 read many" (WORM)コンプライアンスには、オブジェクトは削除または変更できないことが求められます。保持ルールを使用してWORMコンプライアンスを実現します。保持ルールはバケット・レベルで構成され、バケット内の個々のオブジェクトすべてに適用されます。保持ルールが削除されるまで(無期限ルール)または指定された期間(期限付きルール)、オブジェクトまたはオブジェクト・メタデータを更新、上書きまたは削除できません。

オブジェクト・ストレージの保持ルール機能がレコード管理および保持に関する規制要件を満たす能力を個別に評価するには、Cohasset AssociateのSEC 17a-4(f)、 FINRA 4511(c)、 CFTC 1.31(c)-(d) and MiFID II Compliance Assessmentを参照してください。

データ・セキュリティのチェックサム

オブジェクトのデータ整合性を確認するには、オブジェクト・ストレージにアップロードされたすべてのオブジェクトに対してMD5チェックサムを指定します。また、オブジェクト・ストレージにアップロードされたオブジェクトには、次のいずれかのオプション・チェックサムを適用できます:

  • SHA256

  • SHA384

  • CRC32C

MD5チェックサムの使用

オブジェクトのオフラインのMD5チェックサムが、アップロード後にコンソールまたはAPIから返されるチェックサム値と一致するかどうかを検証することをお薦めします。Oracle Cloud Infrastructureでは、オブジェクト・チェックサム値がbase64エンコーディングで提供されます。base64エンコードされたチェックサム値を16進値に変換するには、次のコマンドを使用します:

python -c 'print "BASE64-ENCODED-MD5-VALUE".decode("base64").encode("hex")'

Linuxでは、オブジェクトのMD5チェックサム値を16進形式で計算するためのmd5sumコマンドライン・ユーティリティが提供されています。

マルチパート・アップロードでのMD5チェックサムの使用

オブジェクト・ストレージでは、特にラージ・オブジェクトのより効率的でレジリエントなアップロードのためのマルチパート・アップロードがサポートされています。マルチパート・アップロードでは、パート・サイズMiB単位で指定すると、大容量オブジェクトが小さいパートに分割されます。各パートは個別にアップロードされます。その後、オブジェクト・ストレージによってすべてのパートが結合され、元のオブジェクトが作成されます。いずれかのパートのアップロードが失敗した場合は、オブジェクト全体ではなく、それらのパートのみのアップロードを再試行する必要があります。

マルチパート・アップロードでは、各パートのMD5チェックサム値が計算され、個々のチェックサム値すべてに対してMD5チェックサムが計算されて、出力のMD5値が取得されます。マルチパート・アップロードで返されるMD5値を検証するには、オフラインMD5チェックサム計算と同じプロセスに従います。オブジェクト・ストレージへのマルチパート・アップロードのMD5チェックサム値のオフライン計算のサンプル・スクリプトは、https://gist.github.com/itemir/f5bc9fded6483cd79c89ebf4ca1cfd30で入手できます。

SHA256またはSHA384チェックサムの使用

一部の業界では、MD5よりも強力なチェックサム・メソッドを使用する規制要件があります。多くの場合、これらの要件にはSHA256またはSHA384が明示的に必要です。コンプライアンス制度で必要なアルゴリズムを選択できます。MD5の存在は安全でない、またはコンプライアンスが不足しているとはみなされないことに注意してください。別のチェックサム・メソッドを追加すると、追加の整合性チェックが提供されます。これらの要件を満たすために、SHAチェックサム・タイプのいずれかを追加することが期待されます。

次に、SHA256またはSHA384チェックサムの使用例を示します。
~ echo "Test" | openssl dgst -sha256 -binary | base64
ydBMlWX8ZlyAaB+x2CmTgCaHH2bhT1AeCFMd9mk4p4k=
~ echo "Test" | openssl dgst -sha384 -binary | base64
B6T9J1V45Pkr3wb9V8ioT3u/WNk2zCkY4lAKZ3wYXfDUe2ImwIpVK8O42uUOANY2

CRC32Cチェックサムの使用

ローカル・ストレージ・システムで計算されたチェックサムと、オブジェクト・ストレージで計算されたチェックサムを比較できます。計算されたチェックサムは各パートの正確なサイズに依存するため、マルチパート・アップロードではこれが困難です。これは、異なるシステム(または異なるアップロード設定)で異なる場合があります。

CRC32Cチェックサム・タイプは、アップロード方法に関係なく、同じオブジェクトに対して同じチェックサムを返すように設計されています。これにより、マルチパート・アップロード設定に関係なく、オブジェクト・ストレージによって計算されたCRC32Cチェックサムを、ローカル・ストレージまたは他のクラウドによって計算されたCRC32Cチェックサムと比較できます。

追加のチェックサム・タイプの使用

アップロードされたオブジェクトごとに追加のチェックサム・タイプは1つのみ使用できます。MD5チェックサムは、すべてのオブジェクトに対して常に計算されます。追加のチェックサム・タイプを使用する場合、GETおよびPUTコマンドでは、追加のチェックサム・タイプがない同じオブジェクトのGETまたはPUTと比較して、完了までの待機時間が若干長くなることがあります。

ネットワーク・セキュリティ

Object Storageのリソースへのネットワーク・アクセスを保護します。

顧客クライアント(SDKやCLIなど)とオブジェクト・ストレージのパブリック・エンドポイント間の転送中のデータは、デフォルトでTLS 1.2で暗号化されます。FastConnectパブリック・ピアリングを使用すると、パブリック・インターネットではなくプライベート・ネットワークを介してObject Storageにオンプレミスでアクセスできます。オンプレミス・ネットワークへのアクセスを参照してください。

監査中

オブジェクト・ストレージのアクセス・ログおよびその他のセキュリティ・データを特定します。

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

テナンシでクラウド・ガードを有効にした場合、潜在的なセキュリティ上の問題があるユーザー・アクティビティがレポートされます。問題を検出すると、クラウド・ガードは修正アクションを提案します。特定のアクションを自動的に実行するようにクラウド・ガードを構成することもできます。クラウド・ガードのスタート・ガイドおよびレポートされた問題の処理を参照してください。

この記事は役に立ちましたか。