資産の保護

  • [アーティクル]

資産には、ノート PC、データベース、ファイル、仮想ストレージ アカウントなど、実際および仮想の品目が含まれます。 ビジネスに不可欠な資産のセキュリティ保護は、多くの場合、基になるシステム (ストレージ、データ、エンドポイント デバイス、アプリケーション コンポーネントなど) のセキュリティに依存します。 最も重要な技術資産は通常、データと、アプリケーション (ビジネス Web サイト、生産ライン、通信など) の可用性です。

資産の保護では、セキュリティのアーキテクチャ、標準、およびポリシーをサポートするコントロールが実装されます。 資産の種類とセキュリティ要件の 1 つ 1 つは独特です。 任意の資産の種類のセキュリティ標準は、すべてのインスタンスに一貫して適用される必要があります。

資産の保護では、すべてのコントロールの種類にわたる一貫した実行に重点が置かれています。 予防や検出などは、ポリシー、標準、およびアーキテクチャに適合するように調整されます。

資産の保護は、資産の技術的な領域のエキスパートとして機能します。 これは、ガバナンス、アーキテクチャ、セキュリティ運用、ワークロード チームなどの他の規範と連携します。 資産の保護により、ポリシーと標準が実施可能であることが保証され、ポリシーと標準をサポートするコントロールの実装が可能になります。 資産の保護からは、継続的な改善のためにフィードバックが提供されます。

Note

資産の保護は、通常、資産を保守する IT 運用チームによって実装され、セキュリティ チームの専門知識によって補完されます。 詳細については、「チームとしてコントロールを設計する」を参照してください。

脅威アクターは執拗であり、標準およびポリシーの適用におけるギャップから生じる脆弱性を探し出します。 攻撃者は、ビジネスに不可欠なデータまたはアプリケーションを直接標的にする可能性があります。 また、ビジネスに不可欠なデータとアプリケーションへのアクセス権を彼らに付与するインフラストラクチャを標的にする可能性もあります。 アクセスの制御では、リソースへの承認されたアクセスの管理に重点が置かれています。 資産の保護は、リソースに対するアクセス権または制御権を得るためのその他の例外的な方法すべての可能性に対処します。 これらの 2 つの規範は相互に補完するため、アーキテクチャ、ポリシー、標準に適合するように共同で設計する必要があります。 詳細については、「アクセスの制御」を参照してください。

資産の保護と資産の管理の概要を示す図。セキュリティの確保とセキュリティの維持のセクションがある。

資産保護の歴史と、古い資産と新しいものの両方をセキュリティで保護する方法については、次のビデオをご覧ください。

セキュリティを確保する

セキュリティの確保では、リソースを組織の現在のセキュリティ標準、ポリシー、およびアーキテクチャに適合させることに重点が置かれています。 次の 2 種類のアクティビティがあります。

  • ブラウンフィールド: 現在のセキュリティ標準と既存の資産に対するコントロールを改良します。 組織が IT 環境を設計および運用する場合に、セキュリティの優先度が低い場合があります。 このようなアプローチでは、脆弱なセキュリティ構成、アップグレードされていないソフトウェア、暗号化されていない通信またはストレージ、レガシ ソフトウェアとプロトコルなどの "技術的負債" が発生します。 セキュリティ コントロールを現在のアプローチに取り込んでください。 攻撃者はこれらの機会を悪用する能力を継続的に向上させているので、この改善はリスクを軽減するために重要です。
  • グリーンフィールド: 新しい資産と新しい資産の種類が標準に合わせて構成されるようにします。 このプロセスは、インスタント レガシまたはブラウンフィールド、または現在の標準を満たしていないシステムを継続的に作成しないようにするために重要です。 この技術的負債は、後により多額の費用で対処する必要があります。その結果、それが完了するまでリスクの暴露が増加します。

財務的には、"セキュリティの確保" は一般的に 1 回限りの投資の資本支出 (CAPEX) のダイナミクスにマップされます。 セキュリティのための "グリーンフィールド予算" は、新しいソフトウェア プロジェクト、主要なソフトウェア アップグレード、または全体的なクラウド導入の取り組みごとに、セキュリティの予算の確保割合を指定して、実現できる限り緊密に資産の作成にマップされる必要があります。 多くの組織は、セキュリティのために予算の約 10 パーセントを確保します。 "ブラウンフィールドの予算" は通常、セキュリティ コントロールを現在の標準およびコンプライアンスに適合させるために資金が供給される特別なプロジェクトです。

セキュリティを維持する

時間の経過に伴い、あらゆるものが劣化します。 物理的な品目は消耗します。環境は、仮想の品目 (ソフトウェア、セキュリティ コントロール、セキュリティなど) を中心に変化します。 これらは、変化する要件を満たさなくなっている可能性があります。 これらの変遷は今日、次の急激な変化が原因で急速に生じています。

  • デジタル変革によって推進されるビジネス要件。
  • クラウド プラットフォームの急速な進化と機能のリリースによって推進されるテクノロジの要件。
  • 攻撃者のイノベーションとネイティブ クラウド セキュリティ機能の急速な進化によって推進されるセキュリティ要件。

この原動力は、セキュリティ運用、アクセスの制御、特にイノベーションのセキュリティの DevSecOps など、セキュリティのすべての部分に影響します。

セキュリティの維持には、多くの要素が含まれます。 資産の保護の次の 2 つの特定領域に焦点を当ててください。

  • 継続的なクラウドの改善: クラウドで提供されるセキュリティ機能の継続的な改善を受け入れます。 たとえば、Azure Storage や Azure SQL Database など、Azure の多くのサービスでは、攻撃者に対して防御するセキュリティ機能が経時的に追加されています。
  • ソフトウェアのサポート終了: オペレーティング システムを含むすべてのソフトウェアは、セキュリティ更新プログラムが提供されなくなると、必ずサポート終了となります。 この状況では、ビジネスに不可欠なデータとアプリケーションが低コストで簡単な攻撃にさらされる恐れがあります。 サービスとしてのソフトウェア (SaaS) とクラウド インフラストラクチャおよびプラットフォームはクラウド プロバイダーによって保守されますが、企業は多くの場合、インストールや作成を行う、保守が必要な大量のソフトウェアを保有しています。

サポート終了のソフトウェアのアップグレードまたは廃止を計画してください。 セキュリテ態勢に投資することで、大規模なセキュリティ インシデントのリスクが軽減されます。 "セキュリティの維持" は、通常の継続的な投資の運用支出 (OPEX) のダイナミクスの一部です。

パッチのジレンマ

IT とセキュリティのリーダーとチームをサポートすることは、ビジネス リーダーにとって重要です。 非友好的な環境での複雑なソフトウェアの実行には、固有のリスクがあります。 セキュリティと IT のリーダーは、運用上のリスクとセキュリティ リスクについて常に難しい判断を求められます。

  • 運用上のリスク: システムが実行されるソフトウェアの変更により、ビジネス プロセスが中断される恐れがあります。 このような変更は、組織向けにシステムがカスタマイズされたときの前提に影響を及ぼします。 この事実により、システムの変更を回避しなくてはならないという圧力が生じます。
  • セキュリティ リスク: 攻撃によって、ダウンタイムのビジネス リスクが発生します。 攻撃者は、リリース時にすべての主要なセキュリティ更新プログラムを分析します。 彼らは、セキュリティ更新プログラムを適用していない組織を攻撃するために、24 時間から 48 時間以内に実際に動作する悪用手段を開発できます。

継続的なテクノロジの変化と攻撃手法の進化により、組織はこのジレンマに陥る可能性が多々あります。 ビジネス リーダーは、複雑なソフトウェアを使用してビジネスを行うリスクを認識する必要があります。 次の例のようなビジネス プロセスの更新をサポートします。

  • 事業運営上の想定、スケジュール、予測、その他のビジネス プロセスへのソフトウェア メンテナンスの統合。
  • メンテナンスを容易にし、事業運営への影響を軽減するアーキテクチャへの投資。 このアプローチには、既存のアーキテクチャの更新、またはクラウド サービスまたはサービス指向アーキテクチャに移行することで新しいアーキテクチャへの完全な移行が必要になる可能性があります。

ビジネス リーダーのサポートがない場合、セキュリティと IT のリーダーは、重要なビジネス目標達成のサポートに集中できなくなります。 彼らは、何も得られない状況の駆け引きに絶えず対処する必要があります。

ネットワークの分離

ネットワークの分離は、セキュリティで保護できなくなったが、すぐに廃止できない古い資産を保護するための有効なオプションである場合があります。 このシナリオは、通常、オペレーティング システムとアプリケーションのサポートが終了した場合に発生する可能性があります。 これは、運用テクノロジ (OT) 環境とレガシ システムで一般的です。

セキュリティで保護できない資産は資産の保護の一部として識別されますが、分離自体はアクセスの制御と見なされます。 詳細については、「ファイアウォールを回避して忘れる」を参照してください。

サポート終了状態にある一部のシステムは、完全に切断して分離することが困難です。 これらの安全でないシステムを運用ネットワークに完全に接続したままにしておくことはお勧めしません。 このような構成により、攻撃者がシステムを侵害し、組織内の資産にアクセスできるようになる恐れがあります。

10 年間以上適切に機能しているコンピューター テクノロジをアップグレードまたは置換することは、決して低コストでも簡単でもありません。 その機能に関するドキュメントが限られている可能性があります。 ビジネスに不可欠な複数の資産の制御を失った場合のビジネスへの潜在的影響は、多くの場合、アップグレードまたは置換のコストを上回ります。 分離できないこれらの資産について、組織は多くの場合、クラウドのテクノロジと分析を使用したワークロードの最新化により、アップグレードまたは置換のコストを相殺または正当化できる新しい事業価値を生み出すことができることに気付きます。

常に変化している世界では、セキュリティを維持することは困難です。 どの資産を最新化し、どれをセキュリティで保護するかを、できる限り絶えず決定することが重要です。 評価にはビジネス リスクとビジネスの優先順位を使用してください。

作業の開始

資産の保護を開始するには、組織で次の手順を実行することをお勧めします。

  • 最初によく知られているリソースに焦点を当てる: チームが既に使い慣れている、クラウド内の仮想マシン、ネットワーク、および ID について検討します。 この手法を使用すると、すぐに作業を進めることができ、多くの場合、Microsoft Defender for Cloud のネイティブ クラウド ツールによる管理やセキュリティ保護がより簡単になります。

  • ベンダーまたは業界のベースラインから始める: よく知られている実証済みのソリューションを使用してセキュリティ構成を開始します。次に例を示します。

    • Azure セキュリティ ベンチマークのセキュリティ ベースライン。 Microsoft は、個々の Azure サービスに合わせたセキュリティ構成に関するガイダンスを提供しています。 これらのベースラインによって、Azure のセキュリティ ベンチマークが各サービスの固有の属性に適用されます。 このアプローチを使用すると、セキュリティ チームは各サービスをセキュリティで保護し、必要に応じて構成を調整できます。 詳細については、「Azure のセキュリティ ベースライン」を参照してください。
    • Microsoft セキュリティ ベースライン。 Microsoft は、Windows、Microsoft Office、Microsoft Edge など、一般的に使用されるテクノロジのセキュリティ構成に関するガイダンスを提供しています。 詳細については、「Microsoft セキュリティベースライン」を参照してください。
    • CIS ベンチマーク。 Center for Internet Security (CIS) は、多くの製品やベンダーに固有の構成ガイダンスを提供しています。 詳細については、「CIS ベンチマーク」を参照してください。

重要な情報

次の重要な要素は、資産の保護プロセスのガイドに役立ちます。

説明責任と実行責任を負うチーム

セキュリティの説明責任は、常に、他のすべてのリスクと利点を所有する、ビジネスの最終的なリソース所有者が持つ必要があります。 セキュリティ チームと領域の専門家は、リスク、軽減策、および実際の実装作業について、説明責任を負う所有者へ助言することの実行責任を共同で負います。

資産の保護の責任は、エンタープライズ規模の資産を管理する IT 運用部門、ワークロードの資産に対する実行責任を負う DevOps および DevSecOps チーム、あるいは IT または DevOps および DevSecOps チームと連携するセキュリティ チームによって遂行される場合があります。

組織がクラウドに移行すると、これらの責任の多くはクラウド プロバイダーに移管できる (たとえば、ファームウェアや仮想化ソリューションの更新)、または軽減できます (たとえば、セキュリティ構成のスキャンと修復)。

共有責任モデルの詳細については、「クラウドにおける共有責任」を参照してください。

クラウドの弾力性

オンプレミスのリソースとは異なり、クラウドのリソースは短時間のみ存在する可能性があります。 必要に応じて、ワークロードは、ジョブを実行するために、サーバー、Azure Functions、その他のリソースのインスタンスを追加で作成できます。 その後、Azure によってリソースは削除されます。 このシナリオは数か月以内に発生する可能性がありますが、数分または数時間以内に発生することもあります。 資産の保護のプロセスと測定においては、この可能性を考慮してください。

クラウドの弾力性には、多くのプロセスの調整が必要です。 これにより、静的レポートの代わりにオンデマンド インベントリを使用して、可視性が向上します。 クラウドの弾力性により、問題を修正する能力も向上します。 たとえば、セキュリティ上の理由で新しい仮想マシンを構築することがすぐに行えます。

例外管理

資産のベスト プラクティスを特定したら、その資産のすべてのインスタンスに一貫して適用します。 場合によっては、一時的な例外を認めますが、特定の有効期限付きで例外を管理する必要があります。 一時的な例外がビジネス上の永続的なリスクにならないようにしてください。

測定値に関する課題

資産の保護のビジネス価値を測定することは困難な場合があります。 ある問題の影響は、実際の障害が発生するまで明らかではありません。 脆弱性に対してセキュリティを更新しないというリスクは、隠されていて目に見えません。

自動ポリシーを優先する

資産の保護に対して Azure Policy などの適用と修復の自動化メカニズムを優先します。 このアプローチにより、手動タスクを繰り返し実行することによるコストと士気の問題を回避できます。 また、人的エラーによるリスクが軽減されます。

Azure Policy を使用すると、中央チームがクラウドをまたがる資産に使用する構成を指定できます。

チームとしてコントロールを設計する

すべてのコントロールは、主要な利害関係者とのパートナーシップとして設計する必要があります。

  • 資産の保護により、資産に関する専門知識、それらに使用できるコントロール、およびコントロール実装の実現可能性が提供されます。
  • ガバナンス チーム は、コントロールがセキュリティ アーキテクチャ、ポリシーと標準、および規制コンプライアンスの要件にどのように適合するかに関するコンテキストを提供します。
  • セキュリティ運用部門は、検出のコントロールについて助言を行います。 彼らは、セキュリティ運用のツール、プロセス、およびトレーニングにアラートとログを統合します。
  • ベンダーとクラウド プロバイダーは、その顧客ベース全体で確認されている既知の問題を回避するために、システムおよびコンポーネントに関する深い専門知識を提供できます。

次のステップ

次にレビューする規範はセキュリティ ガバナンスです