次の方法で共有


セキュリティのトレードオフ

セキュリティは、ワークロードのシステムとそのユーザーのデータの機密性、整合性、可用性の保証を提供します。 セキュリティ制御は、ワークロードと、ソフトウェア開発およびシステムの運用コンポーネントに必要です。 チームがワークロードを設計して運用する場合、セキュリティ対策に関しては、ほとんど妥協することができません。

ワークロードの設計フェーズでは、セキュリティ設計原則に基づく決定と、セキュリティのデザイン レビュー チェックリストのレコメンデーションが他の柱の目標と最適化にどのように影響するかを検討することが重要です。 特定のセキュリティ上の決定は、一部の柱に利益をもたらす可能性がありますが、他のものにとってはトレードオフとなります。 この記事では、セキュリティ保証を確立する場合にワークロード チームが直面する可能性があるトレードオフの例について説明します。

信頼性を備えたセキュリティのトレードオフ

トレードオフ: 複雑さの増大。信頼性の柱は、単純さを優先し、障害点を最小限に抑えることが推奨されます。

  • 一部のセキュリティ制御は、構成の誤りを高める危険性があり、サービスの中断につながる可能性があります。 構成の誤りが発生する可能性があるセキュリティ制御の例には、ネットワーク トラフィック ルール、ID プロバイダー、ウイルス スキャンの除外、ロールベースまたは属性ベースのアクセス制御の割り当てなどがあります。

  • セグメント化の増加は、通常、リソースとネットワーク トポロジとオペレーター アクセスの観点から、より複雑な環境につながります。 この複雑さが原因で、プロセスやワークロードの実行で障害が発生する可能性があります。

  • ワークロード セキュリティ ツールは、多くの場合、ワークロードのアーキテクチャ、操作、およびランタイム要件の多くのレイヤーに組み込まれます。 これらのツールは、回復性、可用性、容量計画に影響を与える可能性があります。 ツールの制限を考慮しないと、エグレス ファイアウォールでの SNAT ポートの枯渇など、信頼性の問題が発生する可能性があります。

トレードオフ: 重大な依存関係の増加。信頼性の柱では、重大な依存関係を最小限に抑えることが推奨されます。 重大な依存関係 (特に外部の依存関係) を最小限に抑えるワークロードでは、障害点をより詳細に制御できます。

セキュリティの柱には、ID とアクションを明示的に検証するワークロードが必要です。 検証は、主要なセキュリティ コンポーネントに対する重大な依存関係を介して行われます。 これらのコンポーネントが使用できない場合、または誤動作した場合は、検証が完了しない可能性があります。 このエラーにより、ワークロードが機能低下状態になります。 これらの重大な単一障害点の依存関係の例を次に示します。

  • イングレス ファイアウォールとエグレス ファイアウォール。
  • 証明書の失効リスト。
  • ネットワーク タイム プロトコル (NTP) サーバーによって提供される正確なシステム時間。
  • Microsoft Entra ID などの ID プロバイダー。

トレードオフ: ディザスター リカバリーの複雑さの増加。ワークロードは、あらゆる形式の障害から確実に復旧する必要があります。

  • セキュリティ制御は、目標復旧時間に影響を与える可能性があります。 この影響は、バックアップされたデータの暗号化を解除するために必要な追加の手順、またはサイトの信頼性トリアージによって作成された運用アクセスの遅延によって発生する可能性があります。

  • セキュリティ制御自体 (シークレット コンテナーとその内容やエッジ DDoS 保護など) は、ワークロードのディザスター リカバリー計画の一部である必要があり、復旧ドリルを通じて検証する必要があります。

  • セキュリティまたはコンプライアンスの要件により、バックアップのデータ所在地オプションまたはアクセス制御の制限が制限され、オフライン レプリカをさらに細分化することで、復旧がさらに複雑になる可能性があります。

トレードオフ: 変化率の増加。ランタイムの変更が発生するワークロードは、その変更により、信頼性に影響を及ぼすリスクにさらされる可能性が高まります。

  • 修正プログラムの適用と更新ポリシーの厳格化により、ワークロードの運用環境の変更が増えます。 この変更は、次のようなソースから発生します。

    • ライブラリの更新またはベース コンテナー イメージの更新により、アプリケーション コードがより頻繁にリリースされる
    • オペレーティング システムの定期的な修正プログラムの適用の増加
    • バージョン管理されたアプリケーションまたはデータ プラットフォームを最新の状態に保つ
    • 環境内のソフトウェアにベンダー パッチを適用する
  • キー、サービス プリンシパル資格情報、証明書のローテーション アクティビティにより、ローテーションのタイミングと新しい値を使用するクライアントによって、一時的な問題のリスクが高まります。

コスト最適化によるセキュリティのトレードオフ

トレードオフ: 追加のインフラストラクチャ。ワークロードのコスト最適化の 1 つのアプローチは、コンポーネントの種類と数を減らし、密度を高める方法を探することです。

一部のワークロード コンポーネントまたは設計上の決定は、システムとデータのセキュリティ (機密性、整合性、可用性) を保護するためにのみ存在します。 これらのコンポーネントは、環境のセキュリティを強化しますが、コストも増加します。 また、それら自体もコスト最適化の対象とならなければなりません。 これらのセキュリティ中心の追加リソースまたはライセンス コストのソースの例を次に示します。

  • 分離のためのコンピューティング、ネットワーク、データのセグメント化。これは、場合によっては個別のインスタンスを実行することを意味し、コロケーションを妨げ、密度を低下させます。
  • 集計と脅威インテリジェンスを実行できる SIEM などの特殊な監視ツール。
  • ファイアウォールや分散型サービス拒否防止などの特殊なネットワーク アプライアンスまたは機能。
  • 秘密度と情報の種類のラベルをキャプチャするために必要なデータ分類ツール。
  • HSM や機密コンピューティング機能など、保存時および転送中の暗号化をサポートする特殊なストレージまたはコンピューティング機能。
  • セキュリティ制御が機能していることを検証し、以前は検出されなかったカバレッジのギャップを明らかにするための専用のテスト環境とテスト ツール。

上記の項目は、運用前リソースとディザスター リカバリー リソース内の運用環境の外部にも存在することがよくあります。

トレードオフ: インフラストラクチャに対する需要の増加。コスト最適化の柱は、低コストの SKU の使用、インスタンスの削減、または消費の削減を可能にするために、リソースの需要を減らすことに優先順位を付けます。

  • Premium SKU: ワークロードのセキュリティ体制を向上できるクラウド およびベンダー サービスの一部のセキュリティ対策は、より高価な SKU またはレベルでのみ見つかる場合があります。

  • ログ ストレージ: 広範なカバレッジを提供する忠実度の高いセキュリティ監視と監査データにより、ストレージ コストが増加します。 また、多くの場合、セキュリティ監視データは、通常、運用上の分析情報に必要な期間よりも長い期間保存されます。

  • リソース消費の増加: インプロセスおよびホスト上のセキュリティ制御によって、リソースに対する追加の需要が生じる可能性があります。 保存中および転送中のデータの暗号化により、需要が増加する可能性もあります。 どちらのシナリオでも、より多くのインスタンス数またはより大きな SKU が必要な場合があります。

トレードオフ: プロセスと運用コストの増加。人的プロセスのコストは、総保有コストの一部であり、ワークロードの投資収益率に考慮されます。 これらのコストの最適化は、コストの最適化の柱のレコメンデーションです。

  • より包括的で厳格なパッチ管理体制は、これらの日常的なタスクに費やされる時間と費用の増加につながります。 この増加は、多くの場合、ゼロデイ攻撃に対するアドホック パッチ適用の準備に投資する期待と結び付けられます。

  • 不正アクセスのリスクを軽減するためにアクセス制御を厳格化すると、ユーザー管理と運用アクセスがより複雑になる可能性があります。

  • セキュリティ ツールとプロセスのトレーニングと認識は、従業員の時間を消費し、資料、インストラクター、場合によってはトレーニング環境のコストも発生します。

  • 規制に準拠するには、監査とコンプライアンス レポートの生成に追加の投資が必要になる場合があります。

  • セキュリティ インシデント対応の準備のための訓練計画と実施には、時間がかかります。

  • キーや証明書のローテーションなど、セキュリティに関連付けられているルーチンおよびアドホック プロセスを設計および実行するには、時間を割り当てる必要があります。

  • SDLC のセキュリティ検証には、通常、特殊なツールが必要です。 組織では、これらのツールの支払いが必要な場合があります。 テスト中に見つかった問題の優先順位付けと修復にも時間がかかります。

  • 侵入テストを含め、ホワイトボックス テストまたはシステムの内部構造を知らずに行うテスト (ブラックボックス テストとも呼ばれる) を実行するために、第三者のセキュリティ専門家を雇用します。

オペレーショナル エクセレンスによるセキュリティのトレードオフ

トレードオフ: 監視とサービス性の複雑さ。オペレーショナル エクセレンスには、アーキテクチャを保守可能で監視可能にする必要があります。 最も保守可能なアーキテクチャは、関係するすべてのユーザーに対して最も透過的なアーキテクチャです。

  • 広域なログ取得がもたらすセキュリティ上の利点は、ベースラインからの逸脱を警告し、インシデント対応を行うためのワークロードに関する高忠実度の洞察を提供することです。 こによって大量のログが生成される可能性があるため、信頼性やパフォーマンスを対象とする分析情報を提供することが困難になる可能性があります。

  • データ マスキングのコンプライアンス ガイドラインに従うと、ログの特定のセグメント、あるいは大量の表形式データも、機密保持のために削除されます。 チームは、この監視のギャップがアラートに与える影響やインシデント対応の妨げとなる可能性を評価する必要があります。

  • 強力なリソース セグメント化により、フロー トレースをキャプチャするためにサービス間の分散トレースと相関関係を追加する必要が生じ、監視の複雑さが増します。 セグメント化により、コンピューティングとデータのサービス提供エリアも増加します。

  • 一部のセキュリティ制御は、設計上のアクセスを妨げるものです。 インシデント対応時に、これらの制御によってワークロード オペレーターの緊急アクセスが遅くなる可能性があります。 そのため、インシデント対応計画では、許容できる効果を実現するために、計画とドリルに重点を置く必要があります。

トレードオフ: 敏捷性の低下と複雑性の増大。ワークロード チームは、時間の経過に伴う配信アクティビティの品質、頻度、効率を向上できるように、その速度を測定します。 ワークロードの複雑さは、運用に伴う作業とリスクに影響します。

  • セキュリティの脆弱性が招くリスクを軽減するために、より厳密な変更制御と承認ポリシーにより、新機能の開発と安全なデプロイが遅くなる可能性があります。 ただし、セキュリティ更新プログラムと修正プログラムの適用に対処すると、より頻繁なデプロイの需要が増える可能性があります。 さらに、運用プロセスにおける人による承認ポリシーで、それらのプロセスの自動化が困難になる可能性があります。

  • セキュリティ テストの結果、優先順位を付けなければならない結果が得られるので、計画された作業がブロックされる可能性があります。

  • 定期、アドホック、緊急のプロセスでは、コンプライアンス要件を満たすために監査ログが必要になる場合があります。 このロギングはプロセスの実行の強固さを高めます。

  • ワークロード チームでは、ロールの定義と割り当ての粒度が高まるにつれて、ID 管理アクティビティの複雑さが増す可能性があります。

  • 証明書管理など、セキュリティに関連付けられている日常的な運用タスクの数が増えると、自動化するプロセスの数が増えます。

トレードオフ: 調整作業の増加。外部との接触やとレビューを最小限に抑えるチームは、業務とタイムラインをより効果的に制御できます。

  • 大規模な組織または外部エンティティからの外部コンプライアンス要件が増加するにつれて、監査者に対するコンプライアンスの達成と証明の複雑さも増します。

  • セキュリティには、ワークロード チームが通常持っていない特殊なスキルが必要です。 これらの能力は、多くの場合、大規模な組織または第三者から提供されます。 どちらの場合も、作業、アクセス、責任の調整が確立されている必要があります。

  • コンプライアンスまたは組織の要件では、多くの場合、侵害の責任ある情報開示のために維持されたコミュニケーション計画が必要です。 これらの計画は、セキュリティ調整の取り組みに組み込む必要があります。

パフォーマンス効率によるセキュリティのトレードオフ

トレードオフ: 待機時間とオーバーヘッドの増加。パフォーマンスの高いワークロードにより、待機時間とオーバーヘッドが削減されます。

  • ファイアウォールやコンテンツの安全フィルターなどの検査セキュリティ制御は、セキュリティで保護されたフローに配置されます。 そのため、これらのフローは追加の検証の対象となり、要求に待機時間が追加されます。 高度に分離されたアーキテクチャでは、分散された性質により、1 人のユーザーまたはデータ フロー トランザクションに対してこれらの検査が複数回発生する可能性があります。

  • ID 制御では、制御されたコンポーネントの各呼び出しを明示的に検証する必要があります。 この検証では、コンピューティング サイクルが消費され、承認のために Network Traversa が必要になる場合があります。

  • 暗号化と暗号化解除には、専用のコンピューティング サイクルが必要です。 これらのサイクルにより、これらのフローによって消費される時間とリソースが増加します。 この増加は、通常、アルゴリズムの複雑さと、高エントロピおよび多様な初期化ベクトル (IV) の生成と相関しています。

  • ログの広範さが増すにつれて、これらのログをストリーミングするためのシステム リソースとネットワーク帯域幅への影響も大きくなる可能性があります。

  • リソースのセグメント化では、ワークロードのアーキテクチャにネットワーク ホップが頻繁に導入されます。

トレードオフ: 構成の誤りの可能性が高まる。パフォーマンス目標を確実に満たすことは、設計の予測可能な実装に依存します。

構成の誤りやセキュリティ制御の過剰な実行は、非効率的な構成が原因でパフォーマンスに影響を与える可能性があります。 パフォーマンスに影響を与える可能性があるセキュリティ制御構成の例を次に示します。

  • ファイアウォール規則の順序付け、複雑さ、数量 (細分性)。

  • ファイル整合性監視またはウイルス スキャナーからキー ファイルを除外できない。 この手順を無視すると、ロックの競合が発生する可能性があります。

  • 保護されているコンポーネントに関係のない言語またはプラットフォームに対してディープ パケット検査を実行する Web アプリケーション ファイアウォール。

次に挙げる他の柱のトレードオフを確認してください。