Cloud Guardが新しいディテクタでデータを保護 (2026/10/24)
Cloud Guardが新しいディテクタでデータを保護 (2026/10/24)
https://blogs.oracle.com/cloud-infrastructure/cloud-guard-protects-data-with-new-detectors
投稿者：Martin Sleeman | Senior Principal Product Manager
AIは企業が構築・自動化できる範囲を拡大する一方で、攻撃者が脆弱性をより迅速に発見・悪用することを可能にしています。Oracle は、顧客のクラウド環境の強化を支援するため、18種類の新しいCloud Guard ディテクタ機能をリリースしました。これらのチェック機能は、露出したデータベース、不要なアクセスパス、脆弱な接続、およびリカバリ保護の欠落を特定します。これらの検出結果を修正することで、データ盗難の機会を減らし、破壊的な攻撃からの復旧を改善できます。
経路全体を保護します
データを保護するには、データベースへのログインを保護するだけでは不十分です。データベースには、ネットワークアクセスを制限し、データセキュリティ対策を強化する必要があります。接続には強力な暗号化が必要であり、認証情報や共有リンクには明確な目的が求められ、バックアップは常に必要です。
これらの調査結果を活用し、データベースへのアクセスを、必要なネットワークとアプリケーションのみに制限してください。そうすることで、外部環境から盗まれた認証情報を直接悪用される機会を減らすことができます。
Cloud Guardディテクタ：
プライベートエンドポイントを持たないAutonomous Database
プライベートエンドポイントのないAutonomous Databaseにフラグを立ててください。古いパスを削除する前に、プライベート接続を設定し、DNSとクライアントアクセスをテストしてください。プライベートエンドポイントがないだけでは、公開されているとは証明されません。
公開アクセス可能なAutonomous Database
情報漏洩の兆候です。許可された送信元を制限するか、プライベートエンドポイントを使用して、盗まれた認証情報を使用した接続試行を含む、あらゆる接続試行を制限してください。アクセス設定を確認してください。この発見はデータ窃盗を証明するものではありません。
公開アクセス可能なMySQLデータベースシステム
パブリックサブネット、インターネットゲートウェイ、および許可型ネットワーク設定をフラグ付けします。実際の到達可能性を確認し、承認されたアプリケーションソースへのアクセスを制限します。パブリックサブネットだけでは、到達可能なパブリックエンドポイントであることは証明されません。
データベースの復旧を明示的な設定にする
アクセス制御は、あらゆる破壊的なミスや管理者権限の侵害を防ぐことはできません。3つの検出ツールが、MySQLの削除保護機能と、MySQLおよびPostgreSQLの自動バックアップをチェックします。
データベースシステムの削除を防止するために、削除保護を有効にしてください。バックアップを有効にし、バックアップが正常に完了したことを確認し、復元テストを実施してください。これにより、データが失われたり破損したりした場合に、障害発生時に使用可能なバックアップが存在しないことが判明するのではなく、復旧オプションが確保されるというメリットがあります。これらのチェックは、バックアップの不変性を確立したり、復元テストに取って代わるものではありません。
Cloud Guardディテクタ：
MySQL削除保護が無効になっています
フラグ MySQL DB システムには削除保護機能がありません。有効にすると、システム削除から保護されます。破壊的な SQL やバックアップの置き換えは防止されません。アクセス制御を確認してください。保護設定を変更するには、こちらをご覧ください。
MySQLの自動バックアップは無効になっています
自動バックアップが設定されていないMySQLシステムにフラグを立てます。スケジュールと保持期間を有効にし、バックアップが正常に完了したことを確認し、復元テストを実施してください。バックアップを有効にしただけでは、システムの不変性や復旧準備が整っているとは言えません。
PostgreSQLの自動バックアップは無効になっています
自動バックアップ機能のないPostgreSQLシステムにフラグを立てます。
接続を強化し、ネットワークアクセスを狭める
ロードバランサーの4つの検出機能は、リスナー接続とバックエンド接続の両方において、脆弱なTLSプロトコルと禁止されている事前定義済みの暗号スイートをチェックします。これらの検出機能に対処することで、アプリケーションが必要とする接続、特にロードバランサーの背後にある見落とされがちな接続が強化されます。
2つのセキュリティリスト検出器は、すべての送信元に公開されている非公開ポートと、制限のない送信先を検出します。これらのルールを厳格化して、不要なサービスへのアクセスを減らし、侵害されたワークロードがデータを送信できる場所を制限してください。適用可能なすべてのルールを確認し、別の許可ルールによって同じパスが開いたままにならないようにしてください。
Cloud Guardディテクタ：
ロードバランサーリスナーにおける脆弱なTLS
TLS 1.2未満のプロトコルを許可するリスナーポリシーをフラグします。クライアントの互換性を確認し、古いバージョンを削除してネゴシエーションを防止します。
ロードバランサーリスナーで禁止されている暗号スイート
フラグによって、定義済みのリスナー暗号スイートが禁止されています。禁止リストを確認し、承認済みのより強力なスイートを選択してください。カスタムスイートは別途審査が必要です。
ロードバランサーバックエンドにおける脆弱なTLS
TLS 1.2未満のプロトコル（またはSSLなし）を許可するバックエンドSSLポリシーにフラグを立てます。ポリシーを更新し、バックエンドの接続性をテストしてください。
ロードバランサーのバックエンドで禁止されている暗号スイート
フラグによって、定義済みのバックエンド暗号スイートが禁止されています。承認済みのより強力なスイートを選択し、互換性をテストしてください。カスタムスイートは別途確認してください。検出器はカスタムスイートを評価しません。
非公開港はあらゆる情報源に開放されている
セキュリティリストに登録された非公開ポートへのアクセスをすべての送信元からブロックすることで、攻撃対象領域を縮小します。お客様は、送信元CIDRとポートを必要なトラフィックのみに制限する必要があります。
発信セキュリティリストへのアクセス権限（すべての宛先）
制限のない送信先をフラグ付けします。依存関係を特定し、必要な送信先のみを許可して接続性をテストします。これにより、潜在的なデータ漏洩経路は制限されますが、許可された送信先へのトラフィックは評価されません。
これらの6つのチェック項目は、必要な接続を保護し、不要な接続を遮断するのに役立ちます。
不要なデータアクセス手段を削除する
これらのIAMディテクタは、認証トークン、顧客秘密鍵、またはデータベース認証情報を作成できるユーザーを特定します。4つ目のディテクタは、オブジェクトストレージバケット上の事前認証リクエスト（PAR）を検出します。これは、リンクを持っている人なら誰でもアクセスできる共有URLです。これらはすべて、最小権限の原則を実装するのに役立ちます。
ユーザー権限とリンクは、業務上の必要性がある場合にのみ保持してください。不要な既存の認証情報を削除し、使用されていない作成権限を無効にし、共有リンクを速やかに期限切れにしてください。これにより、保護すべきアクセス経路が減り、インシデント発生時に取り消す必要のある認証情報とリンクの数も削減できます。
これらのチェックは、発行済みまたは盗難された認証情報ではなく、有効化された認証情報機能を検出します。既存の認証情報を削除したり、使用されていない機能を無効にしたりする前に、統合の依存関係を確認してください。作成を無効にしても、既存の認証情報は取り消されません。
Cloud Guardディテクタ：
認証トークンを作成できるユーザー
認証トークンを作成できるユーザーにフラグを立てます。使用されていないトークンを削除し、不要な機能を無効化することで、不要な認証経路を削減します。
ユーザーは顧客秘密鍵を作成できます
オブジェクトストレージS3互換性APIを含む、顧客秘密鍵を作成できるユーザーにフラグを立てます。文書化された統合要件は保持し、不要な鍵を削除し、使用されていない機能を無効にします。
データベース認証情報を作成できるユーザー
データベース認証情報を作成できるユーザーにフラグを立てます。統合要件を確認し、使用されていない認証情報を削除し、不要な機能を無効にして、データベースへのアクセス経路を削減します。
オブジェクトストレージバケットに対する事前認証済みリクエスト
正当なリンクを含む、あらゆるバケットPARにフラグを立てます。所有権、スコープ、有効期限を確認し、不要なリクエストを削除し、その他のリクエストの有効期限を短くします。URLを保有している人は誰でも、プライベートバケットであっても、許可されたアクセス権を取得できます。
これらの調査結果は、見直しが必要なアクセス権限を特定するものであり、認証情報が不正に作成されたり盗まれたりしたことを証明するものではありません。
ワークロードの基盤をしっかりと管理する
承認されていないイメージはセキュリティ強化プロセスを回避してしまう可能性があり、サポートされていないKubernetesバージョンは、クラスターをサポート対象のメンテナンス期間外に放置してしまう可能性があります。
ComputeイメージとOKEバージョン検出器は、こうしたバージョンずれを検出します。承認済みのイメージから再構築し、クラスターをサポート対象バージョンに維持することで、継続的なパッチ適用と脆弱性管理に加え、アプリケーションデータの保護のための、より一貫性があり保守しやすい基盤を構築できます。
Cloud Guardディテクタ：
承認されていないイメージを使用してコンピューティングリソースを使用する
制裁イメージを格納するコンパートメントを指定すると、Cloud Guard は承認されていない Compute イメージまたはサポートされている OKE ノードプールイメージにフラグを立てます。承認済みのイメージから再構築するか、変更管理を通じて正当な例外を承認してください。承認はマルウェアスキャンやパッチ適用に代わるものではありません。
サポートされていないKubernetesバージョン上のOKEクラスター
OKEクラスタがサポートされているKubernetesバージョンの範囲外であることを示します。サポートされているバージョンにアップグレードし、API、アドオン、およびノードプールの互換性を確認してください。コントロールプレーンのアップグレードだけでは、すべてのワークロードが更新されるわけではありません。
ディテクタを稼働させる
OCI構成検出レシピに含まれる利用可能なチェック項目をテストし、対象がリソースを適切にカバーしていることを確認した上で、検出された項目を修正できる担当者に割り当てることをお勧めします。
ベースラインを有効にする
Cloud Guardディテクタはサービス側のルールであり、各ワークロードにインストールするソフトウェアエージェントではありません。レシピはネイティブなバンドルです。1つのユーザー管理構成レシピを使用することで、18個のチェック項目をまとめて確認できるだけでなく、保持する必要のある既存の構成チェック項目も確認できます。お客様はレシピを複製するだけで、Oracleが管理するレシピを作成する必要はありません。
開始する前に、Cloud Guardとその前提条件を有効にし、管理者がレシピの読み取り、ユーザー管理レシピの管理、および対象ターゲットの管理ができることを確認してください。本番環境にデプロイする前に、ステージング環境またはテスト環境で開始することをお勧めします。
コンソール手順
- OCI Webコンソールを開き、Cloud Guardに移動します。
- レシピを開く。
- OCI構成検出レシピ（Oracle Management）を見つけて、[アクション]メニューから[クローン]を選択します。
- 適切な名前（例：CGデータプロテクター）と説明を付け、レシピコンパートメントとレシピフィールドはそのままにしておいてください（クローンする対象がそこなので）。
- 「コンパートメント」ドロップダウンボックスで適切な管理区画を選択し、「複製」ボタンをクリックします。
- 「レシピ」メニューをクリックし、新しく作成したレシピ（CG Data Protectors）を見つけて開きます。
- ディテクタルールタブを開く
- 検索バーで「ステータス」をクリックし、リストから「無効」を選択すると、無効になっているルールが表示されます。
- 無効になっているルールを選択してから「アクション 有効化」をクリックすると、必要なルールをすべて有効にできます（すべて選択することも可能です）。（または、「…」メニューをクリックして1つずつ有効化することもできます。）
- 確認画面が表示されますので、準備ができたら「有効にする」をクリックしてください。
- 次に、この新しく編集したレシピを、コンパートメントに関連付けられたターゲットに適用する必要があります。
- コンパートメントには1つのレシピしか割り当てることができません。
- 既存のターゲットに割り当てる（そして現在のレシピを置き換える）ことができます。
- 「新しいターゲットを作成」ボタンを選択します。
- 名前と説明を付けてください
- 適用する区画を選択してください
- 「次へ」を選択
- 先ほど作成した検出レシピを選択してください（構成検出レシピ - <レシピ名>、例：Martin-BLOG）。
- インスタンスセキュリティレシピとコンテナセキュリティレシピは空欄のままで構いません。
- 「次へ」を選択
- レシピを確認する
- 「作成」を選択
6. Cloud Guardの問題は24時間以内に発生します。
まとめ
Cloud Guardの新しい検出機能 18 種類について説明しました。これらの検出機能は、安全でない構成のクラウド リソースを警告することで、テナント内のデータを保護するのに役立ちます。重要なリソースがインターネットに直接公開されている場合、データベースが安全でない構成になっている場合、ロード バランサーが脆弱な暗号を使用している場合、ユーザーがリスクのある認証情報を持っている場合、およびコンピューティング インスタンスまたは OKE クラスターが承認されていないイメージまたはバージョンを実行している場合に、アラートを生成します。これらの新しいCloud Guard検出機能をテナントに導入することをお勧めします。
コメント
コメントを投稿