セキュリティおよびコンプライアンスの効果的な戦略について

セキュリティおよびコンプライアンスのアプローチには、設計、監視および最適化の3つの主要な戦略が含まれます。これらの戦略は繰り返し適用され、それぞれを他の戦略にフィードバックできます。

設計方針の作成

包括的なセキュリティ設計戦略では、セキュリティ・プリンシパルを認証および認可するプロセスであるアイデンティティ管理を通じてセキュリティが保証されます。アイデンティティ管理サービスを使用して、ユーザー、パートナ、顧客、アプリケーション、サービスおよびその他のエンティティを認証し、権限を付与します。

また、Oracle Cloud Infrastructureで発生したネットワーク・トラフィック、オンプレミスとOracle Cloud Infrastructureがホストするリソース間、およびOracle Cloud Infrastructureとの間のトラフィックを制御することで、アセットの保護を促進します。セキュリティ対策が実施されていない場合、攻撃者はパブリックIP範囲全体をスキャンするなどの方法でアクセスできる可能性があります。適切なネットワーク・セキュリティ制御により、クラウド・デプロイメントへのエントリを取得しようとする攻撃者を検出、格納および停止するのに役立つ多層防御要素を提供できます。

設計戦略が成功すると、Oracle Cloud Infrastructureのアクセス制御、暗号化およびロギングを使用して機密性の高いデータ・アセットを分類、保護および監視することもできます。また、保存中および転送中のデータにもコントロールが配置されます。

アプリケーションとそれに関連付けられたデータは、クラウド・プラットフォームでビジネス価値のプライマリ・ストアとして機能します。アプリケーションは、使用可能で、高い整合性を提供する必要があるビジネス・プロセスをカプセル化して実行するため、ビジネスにとってリスクのある役割を果たすことができます。アプリケーションでは、機密性、整合性および可用性の高い保証を必要とするビジネス・データも格納および処理されます。したがって、戦略を成功させるには、アプリケーションとデータのセキュリティに重点を置いて有効にする必要があります。

モニタリングおよび監査計画の作成

モニタリング戦略が成功すると、ヘルス・モデリングに重点が置かれます。

状態モデリングとは、監視を通じてワークロードのセキュリティ状態を維持するアクティビティのことです。これらのアクティビティは、現在のセキュリティ・プラクティスが有効かどうか、または新しい要件があるかどうかを示すことができます。状態モデリングには、次のカテゴリを含めることができます。

  • ワークロードおよびワークロードが実行されるインフラストラクチャを監視します。
  • 監査の実施
  • 監査ログを有効化、取得および格納します。
  • セキュリティ修正を更新およびパッチ適用します。
  • インシデントに回答します。
  • 実際のインシデントに基づいて攻撃をシミュレートします。

最適化戦略の作成

クラウドでのセキュリティ操作のためのセキュアなベースラインが確立されたら、セキュリティ・チームは、既存のセキュリティ・プラクティスよりも先に進むことができるクラウド固有のセキュリティ・プロセスおよびコントロールを継続的に調査する必要があります。

何千ものビジネスがクラウド・サービスを正常かつ安全に使用して、俊敏性を高め、ITサービスのコストを削減するためのビジネス目標を達成しています。このベスト・プラクティス・フレームワークは、クラウド・サービスを安全に使用するために必要なセキュリティ・アーキテクチャ、プロセスおよびコントロールを提供するセキュリティ運用組織全体のパターンに対する推奨事項を提供します。セキュアなデプロイメントから開始する以外に、継続的な改善の戦略を実装する必要があります。

セキュリティ設計の原則に従う

このピラーの記事では、設計、監視および最適化の3つの戦略の実装方法を説明し、Oracle Cloud Infrastructureでの実装方法に関する推奨事項を提供します。これらの推奨事項には、それぞれ次のセキュリティ設計原則が実装されています。

これらの原則は、これら3つの主要な戦略をサポートし、クラウドまたはオンプレミス・データ・センター(あるいはその両方のハイブリッド組合せ)でホストされる安全に設計されたシステムを説明します。これらの原則を適用すると、セキュリティ・アーキテクチャが機密性、整合性および可用性の保証を維持する可能性が大幅に高まります。

セキュリティおよびコンプライアンスのベスト・プラクティスには、次の設計原則が実装されています。

  • 攻撃者向けの設計:セキュリティの設計と優先順位付けは、ITチームやアプリケーション・チームが見る方法ではない、環境に対する攻撃者の意見に焦点を当てる必要があります。セキュリティ設計を通知し、侵入テストを使用してテストし、ワンタイム攻撃をシミュレートします。赤のチームを使用して、長期間持続する攻撃グループをシミュレートします。環境内での攻撃者の横方向の動きが含まれるように、エンタープライズ・セグメンテーション戦略およびその他のセキュリティ制御を設計します。攻撃者が環境内のリソースの利用の対象とする潜在的な攻撃対象領域を積極的に測定し、削減します。
    • 要件に基づく権限の制限。ターゲット・リソースおよび必要なアクセス権限に関して、できるだけ細かくポリシーを記述します。
    • ネットワーク・セグメンテーションを実施します。トラフィックを制限してネットワーク・レベルでアプリケーションのデプロイメントを分離し、必要なすべてのネットワーク・フローにallowlistを使用します。過度に許容されるトラフィックを最小限に抑えます。
  • ネイティブ・コントロールの活用:サード・パーティの外部コントロールよりもクラウド・サービスに組み込まれたネイティブ・セキュリティ・コントロールを優先します。ネイティブ・セキュリティ・コントロールはサービス・プロバイダによって維持およびサポートされ、外部セキュリティ・ツールを統合し、それらの統合を長期的に更新するために必要な労力をなくしたり減らしたりします。
  • プライマリ・アクセス制御としてのアイデンティティの使用:クラウド・アーキテクチャのリソースへのアクセスは、主にアクセス制御のためのアイデンティティ・ベースの認証および認可によって制御されます。アカウント制御戦略では、ネットワーク制御や暗号化キーの直接使用ではなく、アイデンティティ・システムを使用してアクセスを制御する必要があります。
  • アカウンタビリティ:資産およびセキュリティ職責の明確な所有権を指定し、否認防止のために処理がトレース可能であることを確認します。また、エンティティに必要最小限の権限が(管理可能な粒度レベルまで)付与されていることを確認する必要があります。
  • 自動化の採用:タスクを自動化すると、リスクを引き起こす可能性がある人為的エラーの可能性が減少するため、IT操作とセキュリティのベスト・プラクティスの両方をできるだけ自動化して人為的エラーを削減する必要があります(同時に、熟練した人間が自動化を管理および監査します)。
  • 情報保護に焦点を当てます。知的財産は組織価値の最大のリポジトリの1つであり、このデータはクラウド・サービス、モバイル・デバイス、ワークステーション、コラボレーション・プラットフォーム(ビジネス価値の創出を可能にするコラボレーションを妨げることなく)など、どこにいても保護する必要があります。セキュリティ戦略は、セキュリティの優先順位付けを可能にし、強力なアクセス制御および暗号化テクノロジを活用し、生産性、ユーザビリティ、柔軟性などのビジネス・ニーズを満たすために、情報およびアセットの分類に基づいて構築する必要があります。
  • 耐障害性を考慮した設計:セキュリティ戦略では、統制が失敗し、それに応じて設計されることを前提としています。セキュリティ状態をより回復性の高いものにするには、複数のアプローチを連携させる必要があります。
    • 継続的なVigilance:組織にリスクをもたらす可能性のある異常および潜在的な脅威に適切なタイミングで対処できるようにします。
    • 多層防御:主要なセキュリティ統制に障害が発生した場合に組織のリスクを軽減するために、設計における追加の管理を検討します。この設計では、プライマリ統制が失敗する可能性、潜在的な組織リスク(ある場合)、および追加統制の有効性(特に、プライマリ統制が失敗する可能性が高い場合)を考慮する必要があります。
    • エッジでの防御:効果的な統合エッジ・セキュリティを検討して、アプリケーションに影響を与える前に脅威を制御します。これは、情報セキュリティ・ポリシーのコンプライアンスのために重要です。
    • 最小権限:これは、任意のアカウントが実行できる損傷を制限するための詳細な防御の形式です。アカウントには、割り当てられたタスクを実行するために必要な最小限の権限を付与する必要があります。アクセスを権限レベルおよび時間で制限します。これは、アカウントへのアクセス権を取得する外部攻撃者、またはセキュリティ保証を誤って(または意図的に内部攻撃と同様に)侵害する内部従業員の損傷を軽減するのに役立ちます。
  • ゼロ信頼と仮定:アクセス・リクエストを評価する場合、リクエストしているすべてのユーザー、デバイスおよびアプリケーションは、整合性が十分に検証されるまで信頼できないとみなされます。アクセス・リクエストは、リクエスタの信頼レベルおよびターゲット・リソースの機密性に基づいて条件付きで付与する必要があります。信頼性の検証(たとえば、マルチファクタ認証のリクエスト)を強化し、生産性目標をサポートするために既知のリスクを修正(認識されたパスワードの変更、マルウェア感染の修正)する手段を提供するために、妥当な試行を行う必要があります。