セキュリティ・アーキテクチャ

クラウド導入のセキュリティ・アーキテクチャとは、デジタル資産、データ、アプリケーション、リソースを潜在的な脅威、脆弱性、不正アクセスから保護するための、クラウド環境内のセキュリティ対策の体系的な設計と実装を指します。

目標

クラウド導入のためのセキュリティ・アーキテクチャの主な目的は、機密情報を保護し、規制へのコンプライアンスを確保し、クラウド・コンピューティングの利点を活用しながらリスクを軽減する、包括的で回復力のあるセキュリティ・フレームワークを確立することです。

役割

セキュリティ・アーキテクチャの責任は、通常、クラウド導入時のセキュリティ・アーキテクチャの形成に関与する複数の役割に該当します。

Cloud Security Architect

クラウド環境に固有の全体的なセキュリティ・アーキテクチャ、ポリシーおよびコントロールの設計と実装を担当します。

サイバーセキュリティ・アナリスト

セキュリティ・イベントの監視と分析、インシデントの管理、脅威への対応を行います。

コンプライアンス責任者

セキュリティ・プラクティスが業界の規制や組織のコンプライアンス要件に適合していることを確認します。

DevSecOpsエンジニア

セキュリティ・プラクティスを開発およびデプロイメント・パイプラインに統合し、アプリケーション・ライフサイクル全体にわたるセキュリティを確保します。

ネットワークセキュリティエンジニア

ファイアウォール、侵入検知システム、アクセス制御などのネットワーク・セキュリティ対策を実装します。

実装

次の情報では、クラウド導入用のセキュリティ・アーキテクチャを実装する際の機能および設計上の考慮事項について説明します。

アイデンティティおよびアクセス管理

強力な認証メカニズムの定義と実施、ロールベースのアクセス制御の実装、ユーザー・アイデンティティの管理、アクセスの定期的な確認を行います。

アクセス・コントロールとアイデンティティ管理

アイデンティティ・アクセス管理(IAM)は、ユーザー・アイデンティティの管理とクラウド・リソースへのアクセスに必要な制御を提供し、認可された個人のみが機密データおよびアプリケーションにアクセスできるようにします。

IAMの必要性は、クラウドの採用によって、複数のクラウド・プラットフォームやサービス間のアクセスを管理する必要性、様々なデバイスや場所からのアクセスを制御する必要性、業界標準や規制標準へのコンプライアンスを強制する必要があるなど、新しいセキュリティ課題が生じるためです。

IAMポリシーを実装するには、次のステップをお薦めします:

保護が必要な重要なアセットおよびリソースを特定します。
これらのアセットへのアクセスを制御するアクセス・ポリシーおよびロールを定義します。
ユーザー・アクセスを管理するためのユーザー・プロビジョニングおよびプロビジョニング解除プロセスを確立します。
マルチファクタ認証(MFA)を実装して、ユーザー・アイデンティティを検証し、不正アクセスのリスクを軽減します。
ユーザー・アクティビティとアクセス・ログを監視して、疑わしい動作を検出して対応します。
アクセス・ポリシーとロールを定期的に確認および更新して、継続的な有効性を確保します。

ジャストインタイム・アクセス

スライド・ウィンドウ有効期限管理によるジャストインタイム(JIT)アクセスは、ユーザーが知る必要があるときにクラウド・リソースに一時的にアクセスできるようにするセキュリティ・モデルです。このアプローチは、攻撃対象領域を最小限に抑え、クラウド・リソースの予期しない誤用を防止するのに役立ちます。

JITアクセスにより、ユーザーは限られた期間、および制限された権限でリソースにアクセスできます。スライド・ウィンドウの有効期限管理では、設定した時間ウィンドウ(30分など)に対するアクセス権が付与され、自動的に失効します。このアプローチは、不正アクセスを防止し、データ侵害やその他のセキュリティ・インシデントのリスクを軽減するのに役立ちます。

次の情報は、スライド・ウィンドウ失効管理によるJITアクセスが、適切なセキュリティ・モデルを維持し、予期しない誤用を防止するために役立つ方法を示しています。

露出の制限: クラウド・リソースへのアクセスを必要なユーザーのみに制限することで、攻撃対象領域が削減され、不正アクセスのリスクが最小限に抑えられます。
資格証明盗難のリスクの軽減: JITアクセスでは、ユーザーは長期のアクセス資格証明を必要とせず、盗難や危険にさらされる可能性があります。代わりに、一時的なアクセスが与えられ、資格情報の盗難のリスクが軽減されます。
最小権限の施行: スライド・ウィンドウの有効期限管理では、限られた時間のみアクセスが付与され、制限された権限が付与されます。このアプローチは、ユーザーに付与されるアクセス・レベルを制限し、データ侵害やその他のセキュリティ・インシデントのリスクを軽減する最小権限の原則を適用するのに役立ちます。
アクセス管理の自動化: スライド・ウィンドウ有効期限管理によるJITアクセスを自動化できるため、多数のクラウド・リソースにわたるアクセス制御の管理と実施が容易になります。
監査性の向上: スライド・ウィンドウ失効管理によるJITアクセスにより、誰がいつクラウド・リソースにアクセスしたかを監査証跡できるため、セキュリティ・インシデントの検出と調査が容易になります。

最小権限アクセス

アクションの実行に必要な最小レベルの権限を実装することは、どのシステムでも良好なセキュリティ状態を維持する上で重要な側面です。この原則は、最小権限の原則(PoLP)と呼ばれ、ジョブ機能の実行に必要な最小アクセス・レベルのみをユーザーに付与する必要があることを示しています。

次の情報は、適切なセキュリティ体制を維持するために、必要な最小レベルの権限を実装することが重要である理由を説明しています。

データ侵害のリスクの軽減: ユーザー権限をジョブ機能の実行に必要なもののみに制限することで、データ侵害のリスクを最小限に抑えることができます。ユーザーのアカウントが侵害されると、攻撃者はシステム全体ではなく、限られたデータ・セットにアクセスできます。
マルウェアおよびウイルスの拡散の制限: ユーザー・アカウントが危険にさらされた場合、システムに導入されたマルウェアまたはウイルスもデータおよびリソースへのアクセスが制限されます。
コンプライアンスの確保: 多くのコンプライアンス規制では、組織は最小権限の原則を実装する必要があります。これにより、組織は、機密データを保護し、コンプライアンスを維持するための適切な措置を講じていることを実証できます。
管理が容易: 権限を必要なもののみに制限することで、ユーザー・アカウントとアクセス制御の管理が容易になります。これにより、セキュリティ・インシデントにつながる可能性のある構成ミスやエラーのリスクが軽減されます。
説明責任の向上: 必要な最小レベルの権限のみがユーザーに付与されると、アクションを追跡および監査しやすくなります。これにより、説明責任が高まり、発生する可能性のあるセキュリティ・インシデントの検出と調査が簡単になります。

アクセス・レビュー

ユーザー権限の定期的な評価は、どのシステムでも良好なセキュリティ状態を維持するための重要な側面です。この評価では、ユーザーに付与された権限を確認して、ユーザーがまだ必要であり、適切な目的に割り当てられていることを確認します。次の情報は、ユーザー権限の定期的な評価が重要な理由を説明しています。

アクセスの制限: 時間の経過とともに、ユーザーはジョブ機能で不要になった権限を蓄積することがあります。不要な権限を定期的に確認および取り消すことで、機密データやリソースへのアクセスが制限され、不正アクセスやデータ漏洩のリスクが軽減されます。
攻撃対象領域の削減: 不要な権限によって、システムの攻撃対象領域が増加し、攻撃に対する脆弱性が増す可能性があります。ユーザー権限を定期的に評価し、不要なアクセスを取り消すことで、攻撃対象領域が減少し、攻撃者が機密データにアクセスしにくくなります。
コンプライアンス: 多くのコンプライアンス規制では、アクセス制御が適切に管理されていることを確認するために、ユーザー権限の定期的なレビューが必要です。これらのレビューを実施することで、関連する規制に準拠していることを確認できます。
権限が適切な目的のために割り当てられていることの確認: ユーザー権限は、ジョブ機能およびビジネス・ニーズに基づいて割り当てる必要があります。定期的な評価を行うことで、権限が目的で使用されたままであることを確認できます。
異常の検出: ユーザー権限の定期的な評価は、異常や権限への不正な変更の検出に役立ちます。これは、潜在的なセキュリティ・インシデントまたはセキュリティ・ポリシー違反を示す場合があります。

インフラストラクチャ・セキュリティ

インフラストラクチャを保護するために、ファイアウォール、侵入検知および予防システム、Webアプリケーション・ファイアウォールおよびその他のセキュリティ対策を構成します。インフラストラクチャ・セキュリティの実装は、データとシステムをサイバー脅威から保護するために不可欠です。

ネットワーク・セキュリティ
- ネットワークを異なるゾーンに分割して、機密システムやデータの信頼できないネットワークへの露出を制限します。
- ファイアウォールを使用して、ネットワーク・セグメント間のトラフィックを制御し、セキュリティ・ポリシーを適用します。
- ネットワーク攻撃を監視およびブロックするための侵入検知および予防システム(IDS/IPS)を実装します。
ファイアウォール
- ファイアウォール・ルールを構成して、すべてのトラフィックをデフォルトでブロックし、ソース、宛先およびポート番号に基づいて必要なトラフィックのみを許可します。
- ステートフル検査を実施して、ネットワーク接続の状態を追跡し、不正アクセスを防止します。
- 仮想クラウド・ネットワーク(VCN)を使用して、ネットワークへのリモート・アクセスを暗号化および保護します。
アイデンティティおよびアクセス管理
- IAMの場合、最小権限モデルを実装します。最小権限モデルでは、ユーザーにジョブ機能の実行に必要な最小アクセス・レベルのみが付与されます。
- マルチファクタ認証(MFA)を使用して、ユーザー・アイデンティティを検証し、不正アクセスを防止します。
- ユーザー・プロビジョニングおよびプロビジョニング解除プロセスを実装して、アクセスが適時に制御された方法で付与および取り消されるようにします。
脆弱性管理
- パッチ管理プロセスを実装して、ソフトウェア更新およびセキュリティ・パッチを適時に制御された方法で適用します。
- 脆弱性を悪用する前に、定期的な脆弱性スキャンを実施して脆弱性を特定および修正します。
- 脅威インテリジェンス・フィードを使用して、新しい脅威を特定し、修復作業に優先順位を付けます。
ロギングおよびモニタリング
- ネットワーク・デバイス、サーバーおよびアプリケーションからセキュリティ・イベント・ログを収集および分析するための一元化されたロギングおよび監視ソリューションを実装します。
- セキュリティ情報およびイベント管理(SIEM)を実装して、セキュリティ・イベントをリアルタイムで関連付けおよび分析し、潜在的なセキュリティ・インシデントに関するアラートを生成します。
- 定期的なセキュリティー監査と侵入テストを実施して、セキュリティー態度の弱点を特定し、是正すること。

ワークロードの分離

クラウド・コンピューティングでは、ワークロードの分離がセキュリティを維持するために不可欠です。これは、同じインフラストラクチャ上で実行されている異なるワークロード間のセキュリティ違反や攻撃の拡散を防ぐのに役立ちます。ワークロードの分離とは、ワークロードがコンピュート、ストレージおよびネットワーキング・リソースに関して相互に分離されるように、ワークロードを分離する方法のことです。この分離により、1つのワークロードが危険にさらされた場合、そのワークロードに損傷が限定され、他のワークロードはセキュアなままになります。

ネットワーク・トラフィックをセグメント化し、仮想プライベート・クラウド(VPC)を使用し、セキュリティ・グループを使用してワークロードを分離します。次の情報では、ワークロード分離のベスト・プラクティスを実装するステップについて説明します。

クリティカルなアセットとデータの特定: 最高レベルのセキュリティを必要とするクリティカルなデータまたはアセットを含むワークロードを特定します。
ワークロード分離ポリシーの定義: ワークロードの機密性と重要度に基づいてワークロードを相互に分離する方法を制御するワークロード分離ポリシーを定義します。
適切なクラウド・サービスの選択: 仮想クラウド・ネットワーク(VCN)、セキュリティ・リストまたはネットワーク・セキュリティ・グループ(NSG)やファイアウォールなどのワークロード分離機能を提供するクラウド・サービスを選択します。
SCNまたはNSGの使用: VCNまたはNSGを使用して、セキュリティ要件に基づいてワークロードをセグメント化します。VCNはネットワーク・レベルの分離を提供し、NSGはトラフィック・フローをより詳細に制御します。
アクセス制御の実装: アクセス制御を実装して、認可された担当者のみが重要なワークロードにアクセスできるようにします。
モニターおよび監査: ワークロード分離ポリシーを定期的に監視および監査して、それらが有効であり、ワークロードがセキュアであることを確認します。
暗号化の実装: ワークロード間の保存中および転送中の機密データを保護するための暗号化を実装します。

懸念の分離

懸念事項の分離は、異なる機能または懸念事項を個別のモジュール、クラスまたはコンポーネントに分割することを促進するソフトウェア設計の原則です。このアプローチにより、複雑なシステムの開発、テスト、保守が容易になります。各コンポーネントは独立して開発でき、他のコンポーネントに影響を与えずに変更できます。

クラウドにセキュリティを実装する際には、懸念事項を分離して、セキュリティ上の懸念事項を他のシステム上の懸念事項から分離できます。この分離により、他のシステム・コンポーネントとは独立して、セキュリティ・ポリシーおよび手順を実装および保守できます。

たとえば、クラウド環境では、懸念事項の分離には、他のシステム・コンポーネントとは別のセキュリティ・ポリシー管理システムの実装が含まれる場合があります。このシステムは、アクセス制御やデータ保護などのセキュリティ・ポリシーの定義と適用を担当し、アプリケーション・サーバーやデータベースなどの他のシステム・コンポーネントとは無関係です。

監査権限およびアクセス・ログ

監査権限ログおよびアクセス・ログを確認することは、すべてのシステムで適切なセキュリティ状態を維持するための重要な側面です。これらのログは、ユーザー・アクティビティ、システム・パフォーマンスおよび潜在的なセキュリティ・インシデントに関する貴重な情報を提供できます。これらのログをセキュリティ情報およびイベント管理(SIEM)システムに転送すると、潜在的なセキュリティの脅威に対処するための洞察力のある情報を生成できます。

次の情報は、監査権限およびアクセス・ログを確認する理由を説明しています。

セキュリティ・インシデントの検出: 監査権限ログおよびアクセス・ログは、不正アクセスの試行やシステム構成の変更などのセキュリティ・インシデントの検出に役立ちます。これらのログを確認することで、組織は潜在的なセキュリティ・インシデントを迅速に特定し、それらを軽減するための適切なアクションを実行できます。
インシデントの調査: セキュリティ・インシデントが発生した場合、監査権限ログおよびアクセス・ログは、インシデントを調査するための貴重な情報を提供できます。これらのログは、インシデントのソース、破損の程度、およびインシデントを軽減するために実行されたステップの特定に役立ちます。
ポリシーの改善: 監査権限ログおよびアクセス・ログを確認すると、セキュリティ・ポリシーおよび手順の改善に役立ちます。これらのログ内のデータを分析することで、機密データおよびリソースをより適切に保護するために、セキュリティ・ポリシーの更新または改善が必要な領域を特定できます。
ユーザー・アクティビティのモニタリング: 監査権限ログおよびアクセス・ログを使用して、ユーザー・アクティビティを監視し、ユーザーがセキュリティ・ポリシーおよび手順に準拠していることを確認できます。これらのログを確認することで、潜在的なセキュリティ・インシデントまたはセキュリティ・ポリシーの違反を示す可能性のある異常なアクティビティまたはパターンを識別できます。
コンプライアンス: 多くのコンプライアンス規制では、組織が監査権限ログおよびアクセス・ログを保守および確認して、アクセス制御が適切に管理されていることを確認する必要があります。これらのレビューを実施することで、関連する規制に準拠していることを確認できます。

データの機密性とコンプライアンス

Payment Card Industry(PCI)、Health Insurance Portability and Accountability Act(HIPAA)、General Data Protection Regulation(GDPR)などの標準に対するデータの機密性とコンプライアンスに関する懸念を理解することは、適切なセキュリティ体制を維持し、機密データを不正アクセスから保護するために重要です。次の情報は、データの機密性とコンプライアンスに関する懸念を理解することが重要な理由を説明しています。

機密データの保護: クレジット・カード情報や個人の健康情報などの機密データを、不正アクセスや盗難から保護する必要があります。データの機密性とコンプライアンスに関する懸念を理解することで、適切なセキュリティ制御を実装して、このデータを保護できます。
法的および財務的な罰則の回避: PCI、HIPAA、GDPRなどの規制を遵守しないと、法的および財務的な罰則が発生する可能性があります。コンプライアンス上の懸念を理解することで、関連する規制に準拠していることを確認し、これらの罰則を回避できます。
顧客信頼の維持: データ侵害によって組織の評判が損なわれ、顧客の信頼が損なわれる可能性があります。適切なセキュリティ制御を実装し、関連する規制に準拠することで、機密データを保護し、顧客の信頼を維持するというコミットメントを示すことができます。次の情報では、セキュリティを損なうことなく、PCI、HIPAA、GDPR、およびその他の同様の標準を維持するためのベストプラクティスについて説明します。
機密データの識別: 個人の健康情報、財務データ、その他の個人を特定できる情報を含むすべての機密データを識別し、このデータを保護するための適切なセキュリティ制御を実装します。
アクセス制御の実装: 機密データへのアクセスは、承認された担当者のみに制限し、データへのアクセスを正当な必要性を持つユーザーのみが許可されるようにアクセス制御を実装する必要があります。
暗号化の使用: 機密データを不正アクセスから保護するには、転送中と保存中の両方で暗号化する必要があります。
アクセスのモニターおよび監査: 機密データへのアクセスを監視および監査して、不正アクセスおよび潜在的なセキュリティ・インシデントを検出する必要があります。
定期的なセキュリティ評価の実施: 定期的なセキュリティ評価は、システムの脆弱性を特定し、適切なセキュリティ制御が実施されていることを確認するのに役立ちます。
従業員のトレーニング: 従業員は、機密データを保護し、関連する規制を遵守することの重要性を理解できるように、セキュリティのベストプラクティスとコンプライアンス要件についてトレーニングする必要があります。

地域法と共有セキュリティモデル

現地のデータ保護に関する法律および規制を理解し、遵守します。共有セキュリティ・モデルを考慮して、クラウド・プロバイダと顧客の間の責任を判断します。

現地法

セキュリティのベストプラクティスとして、グローバルな法律や規制だけでなく、地域の法律も考慮することが重要です。地方の法律は、国、地域、地方自治体によっても大きく異なり、これらの法律に違反すると、個人や組織に重大な影響を及ぼす可能性があります。次の情報は、セキュリティのベスト・プラクティスを改善するために、地域の法律が考慮すべき重要な理由を説明しています。

コンプライアンス: 法的罰則やその他の影響を回避するには、現地の法律への準拠が不可欠です。現地の法律に違反すると、罰金、法的措置、評判が損なわれる可能性があります。
文化的および社会的規範: 現地の法律は、セキュリティのベストプラクティスに影響を与える可能性のある文化的、社会的規範を反映している可能性があります。たとえば、一部の国では、他の国よりも個人情報を共有することが許容される場合があります。これらの規範を理解することは、効果的で文化的に敏感なセキュリティのベストプラクティスを実装するために不可欠です。
新たな脅威: 現地の法律は、特定の地域や国に固有の新たなセキュリティ脅威に対処するように設計されています。これらの脅威を理解し、関連する法律を遵守することで、潜在的なセキュリティ・リスクを先取りし、データとシステムを保護できます。
コラボレーション: 地域の法律に準拠することで、組織と政府間のコラボレーションを促進できます。セキュリティの脅威に対処するために協力することで、信頼を築き、より効果的なセキュリティ対策を構築することができます。

地方の法律違反の影響は深刻かもしれません。違反の性質によっては、組織は罰金、法的措置、評判の低下に直面する可能性があります。場合によっては、現地の法律に違反すると、刑事告発や投獄につながることもあります。これらの影響を回避し、適切なセキュリティ体制を維持するために、関連する地域の法律を理解し、遵守することが不可欠です。

共有セキュリティ・モデル

共有セキュリティ・モデルは、セキュリティの観点からクラウド・プロバイダと顧客間の職責の分割を理解するためのフレームワークです。顧客は、組織の願望を満たすためにセキュリティとガバナンスを実装する責任を理解する必要があります。共有セキュリティ・モデルでは、クラウド・プロバイダと顧客は、次のようにセキュリティの様々な側面を担当します。

クラウド・プロバイダの責任:
- データ・センターの物理セキュリティ
- ネットワーク・インフラストラクチャ・セキュリティ
- ハイパーバイザおよびホスト・サーバーのセキュリティ
- クラウドベースのサービスとプラットフォームのセキュリティ
- 基礎となるシステムのパッチ管理
- 業界固有のセキュリティ標準および規制への準拠
顧客の責任:
- データとアプリケーションのセキュリティ
- アイデンティティおよびアクセス管理(IAM)
- セキュリティ制御の構成
- セキュリティ監視とイベント管理
- 適用可能な規制要件への準拠
- クラウドで実行されるカスタム・コードまたはアプリケーションのセキュリティ

一般に、クラウド・プロバイダは基礎となるクラウド・インフラストラクチャのセキュリティを担当し、顧客はクラウドでホストされるアプリケーションやデータのセキュリティを担当します。特定の責任は、Infrastructure as a Service (IaaS)、Platform as a Service (Paas)、Software as a Service (SaaS)など、使用されているクラウド・デプロイメント・モデルのタイプによって異なる場合があります。

セキュリティ監視とインシデント対応

クラウド環境内で予防的かつ効果的なセキュリティ体制を維持するには、インシデント対応手順の確立に加えて、セキュリティ・イベント、異常および潜在的な違反の継続的な監視の設定が不可欠です。

次の情報では、これらの演習の実装方法について説明します。

継続的な監視

モニタリング・ツールの選択:
- 様々なクラウド・リソースからログ、イベントおよびメトリックを収集および分析できる適切なセキュリティ監視ツールおよびサービスを選択します。
主要なメトリックとイベントを定義します。
- 監視が必要な重要なセキュリティ・メトリック、イベントおよび異常を特定します。たとえば、ログイン障害、異常なネットワーク・トラフィック、不正アクセスの試行、リソース使用率の異常などがあります。
ロギングおよび監査の実装:
- クラウド・サービスおよびアプリケーションのロギングおよび監査を構成します。仮想マシン、コンテナ、データベース、アプリケーションなどの様々なソースからログを収集します。
一元化されたログ管理の使用:
- 一元化されたログ管理システムまたはセキュリティ情報およびイベント管理(SIEM)プラットフォームを使用して、様々なソースからのログ・データを集計、関連付けおよび分析します。
リアルタイム・アラートの設定:
- 潜在的なセキュリティ・インシデントを示す事前定義済のしきい値またはパターンに基づいて、リアルタイムのアラートおよび通知を設定します。
異常検出の使用:
- 機械学習および行動分析手法を使用して、異常なパターンやベースライン動作からの逸脱を検出します。

インシデント対応手順

インシデント分類の使用:
- 重大度および影響に基づいてセキュリティ・インシデントのカテゴリを定義します。インシデントを低、中または高優先度として分類します。
インシデント・レスポンス・チームを設定します。
- セキュリティ、クラウド・テクノロジ、法務およびコミュニケーションの専門知識を持つ個人で構成される、専用のインシデント・レスポンス・チームを確立します。
インシデント検出およびトリアージの使用:
- アラートとログを監視して、潜在的なセキュリティ・インシデントを特定します。各インシデントの範囲、影響および重大度を迅速に評価します。
レスポンス・プレイブックの作成:
- 様々なタイプのインシデントのステップバイステップの手順の概要を示すインシデント・レスポンス・プレイブックを作成します。これらのプレイブックには、封じ込め、根絶、回復のための明確な指示が含まれている必要があります。
演習の封じ込めと軽減:
- インシデントを封じ込め、さらなる損傷を防ぐための即時アクションを実行します。これには、影響を受けるシステムの隔離、漏洩したアカウントの無効化、悪意のあるアクティビティのブロックなどが含まれます。
フォレンジック分析の実行:
- フォレンジック分析を実行して、インシデントの根本原因、エントリ・ポイントおよび範囲を理解します。法的および調査目的で証拠を保持します。
コミュニケーションとレポートを提供:
- インシデントについて、関連する利害関係者(管理、法務、影響を受けるユーザーなど)に通知します。定期的な更新を提供し、オープンな通信チャネルを維持します。
是正およびリカバリを実行します。
- インシデントの原因となった脆弱性または弱点を修正します。影響を受けるシステムを復元し、その整合性を検証して、通常の操作を再開します。
障害後のレビューを実行します。
- インシデント後のレビューを実施し、対応の有効性をアセスメントし、改善すべき点を特定し、インシデント・レスポンス・プレイブックを更新すること。

その他の考慮事項

データ・プライバシ: データ保護規制への準拠を保証し、ユーザー・データのプライバシ制御を実装します。
サードパーティの統合: 外部サービスによる脆弱性を防ぐために、サードパーティの統合を評価および保護します。
地理的な考慮事項: クラウド・リージョンを選択する際には、データの主権とローカライゼーションの要件に注意してください。
継続的な監視: 新しい脅威が出現し、環境が進化するにつれて、セキュリティ対策を定期的に評価および更新します。

制約およびブロッカ

共有責任モデル: クラウド・プロバイダと顧客の間の共有責任モデルを理解し、それに応じて適切なセキュリティ対策を実装します。
レガシー・システム: レガシー・システムを統合すると、互換性の問題のためにセキュリティ上の問題が発生する可能性があります。
意識の欠如: クラウド・セキュリティの慣行やリスクに関する知識が不十分な場合、実装が不適切になる可能性があります。
リソース制限: 予算の制約およびリソースの可用性は、セキュリティ・メジャーの範囲および深さに影響する可能性があります。

次のステップ

クラウド採用のガバナンス・プロセスの定義

Oracle Cloud Infrastructureドキュメント