セキュリティのトレードオフ
セキュリティは、ワークロードのシステムとそのユーザーのデータの機密性、整合性、可用性の保証を提供します。 ワークロードと、システムのソフトウェア開発および運用コンポーネントには、セキュリティ制御が必要です。 チームがワークロードを設計して運用するとき、セキュリティ制御を侵害することはほとんどありません。
ワークロードの設計フェーズでは、セキュリティ設計の原則とセキュリティの設計レビュー チェックリストの推奨事項に基づく決定が、他の柱の目標と最適化にどのように影響するかを検討することが重要です。 特定のセキュリティ上の決定は、一部の柱に利益をもたらす可能性がありますが、他の要素のトレードオフを構成します。 この記事では、セキュリティ保証を確立するときにワークロード チームが遭遇する可能性があるトレードオフの例について説明します。
信頼性に関するセキュリティのトレードオフ
トレードオフ: 複雑さが増しました。 信頼性の柱は、シンプルさを優先し、障害点を最小限に抑えることが推奨されます。
セキュリティ制御によっては、構成ミスのリスクが高まる可能性があり、サービスの中断につながる可能性があります。 構成の誤りが発生する可能性があるセキュリティ制御の例としては、ネットワーク トラフィック ルール、ID プロバイダー、ウイルス スキャンの除外、ロールベースまたは属性ベースのアクセス制御の割り当てなどがあります。
セグメント化が増加すると、通常、リソースとネットワーク トポロジとオペレーター アクセスの観点から、より複雑な環境になります。 この複雑さが原因で、プロセスやワークロードの実行における障害点が増える可能性があります。
ワークロード セキュリティ ツールは、多くの場合、ワークロードのアーキテクチャ、操作、およびランタイム要件の多くのレイヤーに組み込まれます。 これらのツールは、回復性、可用性、容量計画に影響する可能性があります。 ツールの制限を考慮しないと、エグレス ファイアウォールでの SNAT ポートの枯渇など、信頼性イベントが発生する可能性があります。
セキュリティの柱には、ID とアクションを明示的に検証するためのワークロードが必要です。 検証は、主要なセキュリティ コンポーネントに対する重要な依存関係を介して行われます。 これらのコンポーネントが使用できない場合、または正常に動作しない場合は、検証が完了しない可能性があります。 このエラーにより、ワークロードは低下状態になります。 これらの重要な単一障害点の依存関係の例を次に示します。
- イングレスファイアウォールとエグレス ファイアウォール。
- 証明書失効リスト。
- ネットワーク タイム プロトコル (NTP) サーバーによって提供される正確なシステム時間。
- ID プロバイダー (Microsoft Entra ID など)。
セキュリティ制御は、目標復旧時間に影響を与える可能性があります。 この影響は、バックアップされたデータの暗号化を解除するために必要な追加の手順、またはサイトの信頼性トリアージによって作成された運用アクセスの遅延によって発生する可能性があります。
セキュリティ コントロール自体 (シークレット コンテナーとその内容やエッジ DDoS 保護など) は、ワークロードのディザスター リカバリー計画の一部である必要があり、復旧訓練を通じて検証する必要があります。
セキュリティまたはコンプライアンスの要件により、バックアップのデータ所在地オプションやアクセス制御の制限が制限され、オフライン レプリカであってもセグメント化による復旧がさらに複雑になる可能性があります。
パッチ適用と更新ポリシーの厳格化により、ワークロードの運用環境の変更が増えます。 この変更は、次のようなソースから行われます。
- ライブラリの更新やベース コンテナー イメージの更新により、アプリケーション コードがより頻繁にリリースされる
- オペレーティング システムの定期的な修正プログラムの適用の増加
- バージョン管理されたアプリケーションまたはデータ プラットフォームを最新の状態に保つ
- 環境内のソフトウェアにベンダーパッチを適用する
キー、サービス プリンシパル資格情報、証明書のローテーション アクティビティは、ローテーションのタイミングと新しい値を使用するクライアントが原因で一時的な問題が発生するリスクを高めます。
コスト最適化によるセキュリティのトレードオフ
一部のワークロード コンポーネントまたは設計上の決定は、システムとデータのセキュリティ (機密性、整合性、可用性) を保護するためにのみ存在します。 これらのコンポーネントは、環境のセキュリティを強化しますが、コストも増加します。 また、コストの最適化自体の対象となる必要もあります。 これらのセキュリティ中心の追加リソースまたはライセンス コストのソースの例を次に示します。
- 分離のためのコンピューティング、ネットワーク、データのセグメント化。場合によっては、個別のインスタンスを実行して、コロケーションを防ぎ、密度を減らすことが含まれます。
- 集計と脅威インテリジェンスを実行できる SIEM などの特殊な監視ツール。
- ファイアウォールや分散型サービス拒否防止などの特殊なネットワーク アプライアンスまたは機能。
- 秘密度ラベルと情報型ラベルをキャプチャするために必要なデータ分類ツール。
- HSM や機密コンピューティング機能など、保存時および転送中の暗号化をサポートする特殊なストレージまたはコンピューティング機能。
- セキュリティ制御が機能していることを検証し、以前は検出されなかったカバレッジのギャップを明らかにするための専用のテスト環境とテスト ツール。
上記の項目は、多くの場合、運用前リソースとディザスター リカバリー リソース内の運用環境の外部にも存在します。
Premium SKU: ワークロードのセキュリティ体制にメリットをもたらす可能性があるクラウドおよびベンダー サービスの一部のセキュリティ対策は、より高価な SKU またはレベルでのみ見つかる場合があります。
ログ ストレージ: 広範なカバレッジを提供する忠実度の高いセキュリティ監視と監査データにより、ストレージ コストが増加します。 また、セキュリティ監視データは、運用上の分析情報に通常必要な期間よりも長い期間保存されることがよくあります。
リソース消費量の増加: インプロセスとオンホストのセキュリティ制御により、リソースに対する追加の需要が生じる可能性があります。 保存データと転送中データの暗号化によって、需要が増加する可能性もあります。 どちらのシナリオでも、より多くのインスタンス数またはより大きな SKU が必要な場合があります。
より包括的で厳格なパッチ管理体制により、これらの日常的なタスクに費やされる時間とコストが増加します。 この増加は、多くの場合、ゼロデイ悪用のためのアドホックパッチ適用の準備に投資する期待と相まって行われます。
不正アクセスのリスクを軽減するためにアクセス制御を厳格化すると、ユーザー管理と運用アクセスがより複雑になります。
セキュリティ ツールとプロセスのトレーニングと認識は、従業員の時間を取り、資料、講師、場合によってはトレーニング環境のコストも発生します。
規制を遵守するには、監査とコンプライアンス レポートの生成に追加の投資が必要になる場合があります。
セキュリティ インシデント対応の準備のための訓練の計画と実施には時間がかかります。
キーや証明書のローテーションなど、セキュリティに関連付けられているルーチンおよびアドホック プロセスを設計および実行するには、時間を割り当てる必要があります。
SDLC のセキュリティ検証には、通常、特殊なツールが必要です。 organizationは、これらのツールの料金を支払う必要がある場合があります。 テスト中に見つかった問題の優先順位付けと修復にも時間がかかります。
侵入テストを含む、システムの内部作業 (ブラックボックス テストとも呼ばれます) を知らずに実行されるホワイト ボックス テストまたはテストを実行するためにサードパーティのセキュリティ専門家を雇うと、コストが発生します。
オペレーショナル エクセレンスとのセキュリティのトレードオフ
ベースラインからの逸脱とインシデント対応に関するアラートを生成するために、ワークロードに対する忠実性の高い分析情報を提供する広範なログ記録のセキュリティ上の利点。 このログ記録によって大量のログが生成される可能性があるため、信頼性やパフォーマンスを対象とする分析情報を提供することが困難になる可能性があります。
データ マスクのコンプライアンス ガイドラインに従うと、機密性を保護するために、ログの特定のセグメントや大量の表形式データも編集されます。 チームは、この可観測性のギャップがアラートに与える影響やインシデント対応の妨げになる可能性を評価する必要があります。
強力なリソースセグメント化により、フロー トレースをキャプチャするために追加のサービス間分散トレースと相関関係が必要になり、可観測性の複雑さが増します。 セグメント化により、コンピューティングとデータのサービスに対する領域も増加します。
一部のセキュリティコントロールは、設計によるアクセスを妨げるものです。 インシデント対応時に、これらの制御によってワークロード オペレーターの緊急アクセスが遅くなる可能性があります。 そのため、インシデント対応計画では、許容できる有効性を実現するために、計画と訓練に重点を置く必要があります。
セキュリティの脆弱性が発生するリスクを軽減するために、変更制御と承認ポリシーを厳格化すると、新機能の開発と安全な展開が遅くなる可能性があります。 ただし、セキュリティ更新プログラムと修正プログラムの適用に対処すると、より頻繁なデプロイの需要が増加する可能性があります。 さらに、運用プロセスの人間による承認ポリシーを使用すると、それらのプロセスを自動化することがより困難になる可能性があります。
セキュリティ テストの結果、優先順位を付ける必要がある結果が得られるので、計画された作業がブロックされる可能性があります。
定期的、アドホック、緊急のプロセスでは、コンプライアンス要件を満たすために監査ログが必要になる場合があります。 このロギングにより、プロセスの実行の剛性が向上します。
ワークロード チームでは、ロールの定義と割り当ての粒度が増えるにつれて、ID 管理アクティビティの複雑さが増す可能性があります。
証明書管理など、セキュリティに関連付けられている日常的な操作タスクの数が増えると、自動化するプロセスの数が増えます。
より大きなorganizationまたは外部エンティティからの外部コンプライアンス要件が増えるにつれて、監査者に対するコンプライアンスの達成と証明の複雑さも増します。
セキュリティには、ワークロード チームが通常持っていない特殊なスキルが必要です。 これらの能力は、多くの場合、より大きなorganizationまたは第三者から提供されます。 どちらの場合も、労力、アクセス、責任の調整を確立する必要があります。
コンプライアンスや組織の要件では、侵害の責任ある開示のために維持されたコミュニケーション計画が必要なことがよくあります。 これらの計画は、セキュリティ調整作業に組み込む必要があります。
パフォーマンス効率によるセキュリティのトレードオフ
ファイアウォールやコンテンツ フィルターなどの検査セキュリティ制御は、セキュリティで保護されたフローに配置されます。 そのため、これらのフローは追加の検証の対象となります。これにより、要求に待機時間が追加されます。
ID コントロールでは、制御されたコンポーネントの各呼び出しを明示的に検証する必要があります。 この検証では、コンピューティング サイクルが消費され、承認のためにネットワーク トラバーサルが必要になる場合があります。
暗号化と暗号化解除には、専用のコンピューティング サイクルが必要です。 これらのサイクルにより、それらのフローによって消費される時間とリソースが増加します。 この増加は、通常、アルゴリズムの複雑さと、高エントロピおよび多様な初期化ベクトル(IV)の生成と相関している。
ログの広範さが増すにつれて、それらのログをストリーミングするためのシステム リソースとネットワーク帯域幅への影響も大きくなる可能性があります。
リソースのセグメント化では、ワークロードのアーキテクチャでネットワーク ホップが頻繁に導入されます。
構成の誤りやセキュリティ制御の過剰な展開は、非効率的な構成のためにパフォーマンスに影響を与える可能性があります。 パフォーマンスに影響を与える可能性があるセキュリティ制御構成の例を次に示します。
ファイアウォール規則の順序付け、複雑さ、数量 (粒度)。
ファイル整合性モニターまたはウイルス スキャナーからキー ファイルを除外できない。 この手順を無視すると、ロックの競合が発生する可能性があります。
保護されているコンポーネントに関係のない言語またはプラットフォームに対してディープ パケット検査を実行する Web アプリケーション ファイアウォール。
関連リンク
他の柱のトレードオフを調べる:
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示