セキュリティをサポートするクラウド設計パターン
ワークロード アーキテクチャを設計するときは、一般的な課題に対処する業界パターンを使用する必要があります。 パターンは、ワークロード内で意図的なトレードオフを行い、目的の結果に合わせて最適化するのに役立ちます。 また、信頼性、パフォーマンス、コスト、運用に影響を与える可能性がある特定の問題に起因するリスクを軽減するのにも役立ちます。 これらのリスクは、セキュリティ保証の欠如を示している可能性があります。放置すると、ビジネスに重大なリスクが発生する可能性があります。 これらのパターンは、実際のエクスペリエンスによって支えられ、クラウドスケールと運用モデル向けに設計されており、本質的にベンダーに依存しません。 ワークロード設計を標準化する方法として既知のパターンを使用することは、オペレーショナル エクセレンスの構成要素です。
多くの設計パターンは、1 つ以上のアーキテクチャの柱を直接サポートしています。 セキュリティの柱をサポートする設計パターンは、セグメント化と分離、強力な承認、均一なアプリケーション セキュリティ、最新のプロトコルなどの概念に優先順位を付けます。
セキュリティの設計パターン
次の表は、セキュリティの目標をサポートするクラウド設計パターンをまとめたものです。
| Pattern | まとめ |
|---|---|
| Ambassador | ネットワーク通信に関連する横断的なタスクをオフロードすることで、ネットワーク通信をカプセル化および管理します。 結果として得られるヘルパー サービスは、クライアントの代わりに通信を開始します。 この仲介ポイントは、ネットワーク通信のセキュリティを強化する機会を提供します。 |
| フロントエンド用バックエンド | 特定のフロントエンド インターフェイス専用の個別のサービスを作成して、ワークロードのサービス レイヤーを個別化します。 この分離により、1 つのクライアントをサポートするサービス層のセキュリティと承認は、そのクライアントによって提供される機能に合わせて調整でき、API のサーフェス領域が減少し、異なる機能が公開される可能性のあるさまざまなバックエンド間の横方向の移動が減少する可能性があります。 |
| Bulkhead | コンポーネント間で意図的かつ完全なセグメント化を導入し、誤動作の爆発半径を分離します。 この戦略を使用して、侵害されたバルクヘッドに対するセキュリティ インシデントを含めることもできます。 |
| 要求チェック | メッセージング フローからデータを分離し、メッセージに関連するデータを個別に取得する方法を提供します。 このパターンでは、機密データをメッセージ本文から除外し、セキュリティで保護されたデータ ストアで管理し続けるのがサポートされています。 この構成により、データを使用することが期待されるサービスからの機密データへのアクセスをサポートするためのより厳密な承認を確立できますが、キュー監視ソリューションなどの補助サービスからの可視性を削除できます。 |
| フェデレーション ID | ユーザーを管理し、アプリケーションの認証を提供するために、ワークロードの外部にある ID プロバイダーに信頼を委任します。 ユーザー管理と認証を外部化することで、これらの機能をワークロードに実装しなくても、ID ベースの脅威検出と防止のための進化した機能を利用できます。 外部 ID プロバイダーは、最新の相互運用可能な認証プロトコルを使用します。 |
| ゲートキーパー | バックエンド ノードに要求を転送する前と後に、セキュリティとアクセス制御の適用専用の要求処理をオフロードします。 ゲートウェイを要求フローに追加すると、Web アプリケーション ファイアウォール、DDoS 保護、ボット検出、要求操作、認証開始、承認チェックなどのセキュリティ機能を一元化できます。 |
| ゲートウェイ集約 | 1 つの要求で複数のバックエンド サービスへの呼び出しを集計することで、ワークロードとのクライアントの対話を簡略化します。 このトポロジでは、多くの場合、クライアントがシステムに対して持つタッチ ポイントの数が減り、パブリックなサーフェス領域と認証ポイントが減少します。 集約されたバックエンドは、クライアントから完全にネットワーク分離された状態を維持できます。 |
| ゲートウェイ オフロード | 要求をバックエンド ノードに転送する前と後に、ゲートウェイ デバイスに要求処理をオフロードします。 要求フローにゲートウェイを追加すると、Web アプリケーション ファイアウォールやクライアントとの TLS 接続などのセキュリティ機能を一元化できます。 プラットフォームで提供されているオフロードされた機能は、既に強化されたセキュリティを提供します。 |
| パブリッシャー/サブスクライバー | クライアントとサービス間の直接通信を中間メッセージ ブローカーまたはイベント バス経由の通信に置き換えることで、アーキテクチャ内のコンポーネントを分離します。 この置き換えにより、キュー サブスクライバーをパブリッシャーからネットワーク分離できるようにする重要なセキュリティ セグメント化境界が導入されます。 |
| 検疫 | 外部資産をワークロードで使用する承認を受ける前に、チームが合意した品質レベルを満たしていることを確認します。 このチェックは、外部成果物の最初のセキュリティ検証として機能します。 成果物の検証は、セキュリティで保護された開発ライフサイクル (SDL) 内で使用される前に、セグメント化された環境で実行されます。 |
| Sidecar | メイン アプリケーションと共に存在するコンパニオン プロセスに非特権タスクまたはクロスカット タスクをカプセル化することで、アプリケーションの機能を拡張します。 これらのタスクをカプセル化し、それらをアウトプロセスで展開することで、機密性の高いプロセスの領域を、タスクの実行に必要なコードのみに減らすことができます。 サイドカーを使用して、その機能を使用してネイティブに設計されていないアプリケーション コンポーネントにクロスカット セキュリティ コントロールを追加することもできます。 |
| 調整 | リソースまたはコンポーネントへの受信要求のレートまたはスループットに制限を課します。 制限を設計して、システムの自動不正使用に起因する可能性のあるリソースの枯渇を防ぐことができます。 |
| バレット キー | 中間リソースを使用してアクセスをプロキシすることなく、リソースへのセキュリティ制限付きアクセスを許可します。 このパターンにより、クライアントは長期的または永続的な資格情報を必要とせずに、リソースに直接アクセスできます。 すべてのアクセス要求は、監査可能なトランザクションで始まります。 その後、許可されたアクセスは、スコープと期間の両方で制限されます。 このパターンにより、付与されたアクセス権を簡単に取り消すことができます。 |
次の手順
他の Azure Well-Architected Framework の柱をサポートするクラウド設計パターンを確認します。