セキュリティの設計原則

Well-Architectedワークロードは、セキュリティに対してゼロ トラスト アプローチで構築する必要があります。 安全なワークロードは攻撃に対して耐性があり、ビジネス目標の達成に加えて、機密性、整合性、可用性 ( CIAトライアド とも呼ばれる) という相互に関連するセキュリティ原則を組み込んでいます。 あらゆるセキュリティ インシデントは、ブランドと評判に損害を与える重大な違反となる可能性があります。 セキュリティ戦略がワークロードに対してどの程度機能するかを評価するには、次の質問を自問してください。

• セキュリティ対策により、攻撃者がワークロードに侵入する速度がどの程度低下したり、阻止されたりしますか?
• 攻撃が発生した場合、セキュリティ対策によって被害や攻撃の拡大をどの程度抑えることができますか?
• あなたのワークロードは攻撃者にとってどれほど価値があるでしょうか? ワークロードまたはそのデータが盗まれたり、利用できなくなったり、改ざんされたりした場合、ビジネスにどの程度の損害が発生するでしょうか?
• ワークロードの中断をどれだけ早く検出し、対応し、回復できますか?

システムを設計する場合は、セキュリティ リスクを軽減するためのコンパスとして Microsoft ゼロ トラスト モデルを使用します。

• 信頼できるIDのみが、予期される場所から発信される意図された許可されたアクションを実行するように明示的に検証します。 この保護機能により、攻撃者が正規のユーザーやアカウントになりすますことが困難になります。

• 適切なID、適切な権限セット、適切な期間、適切な資産に対して、最小限の権限アクセスを使用します。 アクセス許可を制限することで、正当なユーザーが必要としていないアクセス許可であっても、攻撃者が悪用するのを防ぐことができます。

• セキュリティ制御の侵害を想定し、主要な防御層が失敗した場合にリスクと損害を制限する補償制御を設計します。 これにより、成功に関心のある攻撃者 (成功の手段は問わない) のように考えることで、ワークロードをより適切に防御できます。

セキュリティは一度限りの取り組みではありません。 このガイダンスは定期的に実装する必要があります。 防御とセキュリティに関する知識を継続的に向上させ、自動化された攻撃キットを使用して新しい革新的な攻撃ベクトルを見つけることに長けた攻撃者からワークロードを保護します。

Microsoft Azure Well-Architected Framework に基づく設計原則は、継続的なセキュリティの考え方を育み、脅威の進化に応じてワークロードのセキュリティ体制を改善することを目的としています。 これらの原則は、アーキテクチャ、設計の選択、および運用プロセスのセキュリティを導く必要があります。 推奨されるアプローチから始めて、一連のセキュリティ要件に対する利点を正当化します。 戦略を設定したら、次のステップとして セキュリティ チェックリスト を使用してアクションを推進します。

これらの原則が適切に適用されない場合、事業運営や収益に悪影響を及ぼすことが予想されます。 規制ワークロードに対するペナルティなど、いくつかの結果は明白です。 ただし、その他の脆弱性はそれほど明白ではなく、検出される前に継続的なセキュリティ問題を引き起こす可能性があります。

データ流出などの一部の攻撃ベクトルが信頼性に影響を与えないことを考慮すると、多くのミッション クリティカルなワークロードでは、信頼性と並んでセキュリティが最大の懸念事項となります。 セキュリティ重視の設計では、障害点が生じ、運用の複雑さが増す可能性があるため、セキュリティと信頼性によってワークロードが反対方向にプルされる可能性があります。 セキュリティの信頼性に対する影響は、多くの場合、運用上の制約によって間接的に生じます。 セキュリティと信頼性のトレードオフを慎重に検討してください。

これらの原則に従うことで、セキュリティの有効性を向上させ、ワークロード資産を強化し、ユーザーとの信頼関係を築くことができます。

セキュリティ対策の計画

最小限の摩擦で、アーキテクチャ設計の決定と運用にセキュリティ プラクティスを採用および実装することを目指します。

ワークロード所有者は、資産を保護する責任を組織と共有します。 ビジネスの優先事項に合ったセキュリティ準備計画を立てましょう。 明確なプロセス、十分な投資、適切な責任を確立するのに役立ちます。 計画では、資産を保護する責任も共有する組織にワークロード要件を伝える必要があります。 セキュリティ プランは、信頼性、健全性モデリング、自己保存のための戦略の一部である必要があります。

Azure Well-Architected Frameworkでの セキュリティ準備の計画 の詳細をご覧ください。

機密性を保護する設計

アクセス制限と難読化技術を使用して、プライバシー、規制、アプリケーション、および独自の情報の漏洩を防ぎます。

ワークロード データは、ユーザー、使用状況、構成、コンプライアンス、知的財産などによって分類できます。 確立された信頼境界を超えてそのデータを共有したりアクセスしたりしないでください。 機密性を保護するには、アクセス制御、不透明性、およびデータとシステムに関連するアクティビティの監査証跡の保持に重点を置く必要があります。

Azure Well-Architected Frameworkにおける 機密性を保護するための設計 の詳細をご覧ください。

完全性を保護する設計

システムが期待される価値を提供できなくなったり、定義された制限外で動作したりする原因となる中断を防ぐために、設計、実装、運用、およびデータへの損傷を回避します。 システムは、ワークロードのライフサイクル全体にわたって情報保証を提供する必要があります。

重要なのは、ビジネス ロジック、フロー、デプロイメント プロセス、データ、さらにはオペレーティング システムやブート シーケンスなどの下位スタック コンポーネントの改ざんを防止するコントロールを使用することです。 整合性が欠如すると脆弱性が生じ、機密性と可用性の侵害につながる可能性があります。

Azure Well-Architected Frameworkでの 整合性を保護するための設計 の詳細をご覧ください。

可用性を保護する設計

強力なセキュリティ制御を使用することで、セキュリティ インシデントが発生した場合でも、システムとワークロードのダウンタイムやパフォーマンスの低下を回避または最小限に抑えることができます。 インシデント発生中およびシステムの回復後もデータの整合性を維持する必要があります。

可用性アーキテクチャの選択とセキュリティ アーキテクチャの選択のバランスを取る必要があります。 システムは、ユーザーがデータにアクセスでき、データが到達可能であることを保証するために、可用性の保証を提供する必要があります。 セキュリティの観点から、ユーザーは許可されたアクセス スコープ内で操作し、データを信頼する必要があります。 セキュリティ制御は悪意のある行為者を阻止する必要がありますが、正当なユーザーがシステムやデータにアクセスするのを阻止してはなりません。

Azure Well-Architected Frameworkでの 可用性を保護するための設計 の詳細をご覧ください。

セキュリティ体制を維持し、進化させる

攻撃戦略を継続的に進化させている攻撃者より一歩先を行くために、継続的な改善と警戒を怠らないようにしましょう。

セキュリティ体制は時間の経過とともに悪化してはなりません。 新たな混乱にさらに効果的に対処できるように、セキュリティ運用を継続的に改善する必要があります。 業界標準で定義されたフェーズに合わせて改善を進めることを目指します。 そうすることで、準備態勢が向上し、インシデントの検出時間が短縮され、効果的な封じ込めと緩和が可能になります。 継続的な改善は、過去のインシデントから学んだ教訓に基づく必要があります。

詳細はこちら セキュリティ体制の維持と進化 Azure Well-Architected Frameworkで。

次の手順

セキュリティ チェックリスト