すべての連邦政府機関がエンタープライズ アプリケーション戦略を必要とする理由とその構築方法

米国連邦政府機関のIT担当役員は、サイバー攻撃による消耗を減らし、またサイバー攻撃による損失を最小限に抑えながら、より多くの価値を提供するために細心の注意を払う必要があります。一方、ITリーダーは、より高い効率性を実現し、より多くの価値を提供し、納税者のお金を節約するために、最新のテクノロジーを取り入れなければなりません。また、ITリーダーは、進化・拡大する脅威の状況に直面しており、その緩和のために多大なリソースを必要としています。つまり、あらゆる取り組み、あらゆる決断において、革新と保護の両立が求められているのです。この一見相反する目標を達成するために、連邦政府のITリーダーは、組織のミッションに合わせたエンタープライズ アプリケーション戦略を策定する必要があります。

F5の2019年の「アプリケーション サービスの状況」レポートで調査した回答者の65％が、自分の組織はデジタル トランスフォーメーションの真っ只中にあると回答しています。デジタル トランスフォーメーションとは、組織がテクノロジを利用してパフォーマンスとユーザーの生産性の大幅な向上を実現するための新しい方法です。

つまり、アプリケーションがビジネスやミッションそのものになりつつあるのです。

この急激な変化をうまく活かすため、組織は新しいビジネスとITの運用モデルを追求しながら、次のような抜本的な改革を進めています。

• クラウドベースのメールやプロダクティビティ ツールなどのSaaSサービスの利用
• カスタム アプリケーションのコンテナ化により、管理の簡素化とコスト削減を実現
• クラウド セキュリティ サービスを利用することで、攻撃を迅速に特定し、組織のルールに応じてポリシーを適用

アプリケーションは、さまざまなタイプのデバイスに導入されています。アプリケーションにアクセスするユーザーは、従来の企業環境内にいるわけではなく、モバイルや在宅勤務をしています。CRMやERPなど、ビジネスクリティカルな機能を提供するには、従来の企業ネットワークの外からアクセスできるようにする必要があります。

2018年のF5 Labsの「アプリケーション プロテクション レポート」によると、平均的な公共部門では680のアプリケーションを使用しており、そのうちの32％がミッション クリティカルとみなされていることが明らかになりました。

このようなアプリケーションの膨張に加え、組織はそれらのアプリケーションを新しいアーキテクチャとサービスに導入しています。2019年の「アプリケーション サービスの状況」調査によると、調査対象の組織の14％がコンテナをデフォルトのアプリケーション ワークロード分離アプローチとし、回答者の87％がマルチクラウド アーキテクチャを採用していることがわかります。米国行政管理予算局（OMB）自身も、安全でセキュアなクラウド ネットワークに移行するための「クラウド スマート戦略」¹を提唱しています。

煩雑さを軽減し、新しいサービスを提供して、価値を高めるためにテクノロジーを利用しているのは、政府機関や商業組織だけではありません。サイバー犯罪者、過激派グループ、国家レベルの攻撃者も、サイバー攻撃能力を猛烈なスピードで革新しています。私たちのネットワークやインフラストラクチャの保護が強化されるにつれ、サイバー攻撃者はよりソフト ターゲットに狙いを変えつつあります。

ソフト ターゲットは、人事や機密情報を保管するような高い価値のある資産に侵入するために使用されます。F5 Labsの調査によると、全サイバー攻撃者の86％は、アプリケーションを直接標的とするか、通常はフィッシングによってユーザーIDを盗んでいることが分かっています。²

攻撃者は、間接的に攻撃する方が簡単な場合があることを学んでいます。その1つが、IoTデバイスなどの重要度の低いアプリケーションを狙い、アクセスをレベル アップさせる方法です。犯罪者が米国のカジノにあるロビーの水槽の温度計を通じてカジノをハッキングし、大金を賭けている人のデータベースへの足がかりとして利用したケースがそうでした。³同様に、2013年に発生したTargetの壊滅的な侵害は、Targetの空調ベンダーの悪用から始まり、POSシステムの侵害と4,000万人分のクレジット カード情報の損失という結果をもたらしたのです。⁴

アンマネージド状態のオープン ソースや他のサードパーティのコンポーネントおよびサービスもリスクをもたらす可能性があります。Sonatypeの「2018年のソフトウェア サプライ チェーンの現状」では、オープン ソース コンポーネントのダウンロードの8件中1件に既知のセキュリティ脆弱性が含まれていると指摘しています。⁵公共部門を含む組織は、開発・提供をスピード アップするため、オープン ソースを活用しています。しかし、これらの組織では、セキュリティ スキャンやレビュー プロセスにオープン ソース コンポーネントを含めないことがよくあります。これらのコンポーネントは、アプリケーション ポートフォリオの一部となるため、カスタム コードと同じように慎重に扱う必要があります。これには、クライアント サイドだけでなく、サーバー サイドのコンポーネント（NPMパッケージ、ライブラリなど）も含まれます。

アプリケーションは、組織の目標を達成するうえでより重要な役割を果たすようになり、これらのアプリケーションの増加は、ほとんどの組織で運用を拡張する能力を上回りつつあります。従来の境界警備のモデルでは、拡張性がなく、脅威を防止する効果も限られています。ソフト ターゲットが侵害されると、高い価値を持つ資産も危険にさらされます。新しいアーキテクチャと導入モデルは、従来のセキュリティ対策にさらなる課題を突きつけています。アプリケーションは分散した場所にステージングされ、パフォーマンス向上のためにマルチクラウド アプリケーション サービスが使用されるようになっています。一方、アプリケーションに関連する脅威の対象領域は、指数関数的に拡大しています。

パフォーマンスを維持しながらセキュリティを提供するには、アプリケーションやソフト ターゲットの近くでの継続的な監視が重要です。インテリジェントなクラウド セキュリティを統合することで、アプリケーションと連携して、脅威を迅速に緩和し、機密データを保護することができます。小さなデータ タイプをクラウドに送信し、クラウド内に保存されている数百万のアーティファクトとデータを比較することで、潜在的な脅威を特定することができます。これは、クライアントがボットなのか実際のユーザーなのかを判断するために使用できます。

不正行為削減サービスは、アプリケーションと連携して攻撃者と対話し、より多くのデータ タイプを取得して、大規模な不正行為を防止することができます。不正行為の完全なプロファイルは、組織の継続的監視システムに導入でき、対策を講じて、攻撃の拡大を防ぎ、侵害されたシステムの場所を特定し、感染したマシンから脅威を取り除くための手順を提供することが可能です。アナリストは、さらなる分析のためにオペレーションに情報を提供することができます。

既に状況は複雑になっているのに、連邦政府機関では、柔軟性の向上、可用性の向上、ベンダーへの依存度の低減、そして場合によってはコスト削減のために、マルチクラウドやSaaSの導入に移行しています。しかし、ハイブリッド、マルチクラウド、SaaSアーキテクチャで、標準化された安全かつシームレスなアプリケーション体験を、予算を超過することなく実現するにはどうすればよいのでしょうか？

機関は、SaaSやマルチクラウド環境への接続をセキュリティで保護するために、信頼できるインターネット接続ポイントで境界ソリューションを使用できます。この場合、機関には接続ポイントが限られているため、パフォーマンスの問題が発生する可能性があります。公開アプリケーションは、セキュリティのためにこれらのポイントを通過する必要があるため、遅延が発生します。セキュリティのためにトラフィックが「トロンボーン」する必要があるため、スケーラブルで高性能なアプリケーションを実現するメリットが失われます。

また、境界ソリューションは、静的なシグネチャに依存しています。新しい脅威が開発され、セキュリティ クラウド プロバイダー内でプロファイリングされた場合、その情報は境界システムに伝達されず、攻撃を防ぐことができません。シグネチャの更新は、1日または1週間以内に行われることがあります。最終的にシグネチャが開発され、境界セキュリティ システム内で更新されたときには、高い価値を持つ資産が危険にさらされる可能性があります。

マルチクラウドとSaaSアプリケーション サービス（アプリケーションの保護、管理、最適化のためのソリューション）を標準化することで、マルチクラウド アーキテクチャに付随する運用の複雑さを軽減することができます。

例えば、ベンダー固有のメッセージ キューイング サービスを使用しなければならないようなプラットフォーム固有のサービスよりも、コードベースのAPI呼び出しやイベント駆動型システムのようなエンタープライズ アプリケーション レベルで機能するサービスの方が、管理しやすく、より強力です。すべてのアプリケーションで1つの機能セットを使用できるようにすることで、運用のオーバーヘッドを削減できます。できるだけ多くのアプリケーション サービスに標準プラットフォームを採用することで、組織はより多くの自動化を活用し、より多くのコードを再利用して、一貫性があり予測可能で再現性のある運用プロセスを実現することができます。

クラウドを活用する多くの企業がIT部門を持たない時代において、従来のITアーキテクチャや運用プロセスは、アプリケーション開発者やDevOpsチームの期待を著しく下回っています。アプリケーションをより迅速に動作させたいという期待により、従来のネットワークやセキュリティのチーム、および関連するセキュリティや運用プロセスを回避することにつながることがよくあります。実際、エンタープライズ アプリケーション ポートフォリオを保護することは、テクノロジーと同様に、人材やプロセスにも大きく関わってきます。

このようなマルチクラウドの乱立する環境でパフォーマンスと、さらに重要なリスクを管理するために、企業はソリューションを必死に求めています。アプリケーションがどこにあっても、ソリューションは一貫したポリシーの導入をサポートし、脅威を管理し、可視性を提供して、アプリケーションの健全性とパフォーマンスの監視を可能にする必要があります。アプリケーション開発チームおよびDevOpsチームのイノベーションと俊敏性が妨げられると、適合性の低いソリューションにより、デジタル トランスフォーメーションから得られるメリットが簡単に減少してしまう可能性があります。

アプリケーションの価値とリスクのプロファイルが増大していることを考えると、すべての連邦政府機関は、エンタープライズ ポートフォリオでのアプリケーションの構築/取得、導入、管理、およびセキュリティ確保を行う方法に対応するエンタープライズ アプリケーション戦略を策定する必要があります。

要約：この機会を利用して、連邦政府機関のミッションおよび目標と合致したエンタープライズ アプリケーション戦略を策定します。

デジタル トランスフォーメーションの要点は、扱いにくい手動のプロセスを、効率的で豊富なデータを備えたアプリケーションに置き換えることです。したがって、エンタープライズ アプリケーション戦略の包括的な目標は、ミッションの実現に関連する組織のデジタル機能を直接的に強化、スピード アップ、および保護することであるべきです。この目標にそぐわないアプリケーションや関連するアプリケーション サービスは、優先順位を下げる必要があります。優先順位の高いアプリケーションには追加のリソースとセキュリティを与え、優先順位の低い資産には共有リソースを使用することができます。

この連携には、現在の企業データ戦略、コンプライアンス要件、組織の全体的なリスク プロファイルを注視するなど、現状を考慮することも含まれます。

多くの場合、これらの異なるソースによって課される制約と、アプリケーション開発チームの俊敏性への影響は、あまりよく理解されていない可能性が高いです。エンタープライズ アプリケーション戦略では、イノベーション、俊敏性、リスクという、しばしば競合する要素間で、どのようなバランスを取ることを機関が望んでいるのかを明確にする必要があります。

要約：モダナイゼーションを開始する前に、完全なアプリケーション インベントリを構築する必要があります。

エンタープライズ アプリケーション戦略に関して、ほとんどのチームは新しく始められるほど恵まれていません。IT業界のほぼ全社が、何十年にもわたって異種システムを統合し、その上にレガシー システムを乗せて機能を維持してきた結果であるテクノロジ アーキテクチャを継承しています。この問題は、商業部門と比較して、米国連邦政府内で特に深刻である可能性があります。このような不一致のあるテクノロジを目的のターゲット状態にきれいに移行できることは稀です。そのため、より多くの検出と分析を行う必要があるのです。

単純すぎると思われるかもしれませんが、何かを適切に保護するためには、まずその存在を知り、次にその健全性を正確に監視する必要があります。しかし、一部の例外を除き、ほとんどの組織は、自社のポートフォリオにあるアプリケーションの数を自信を持って答えることができず、ましてや、そのアプリケーションが健全で安全かどうかを答えることはできません。2018年のF5 Labsの「アプリケーション プロテクション レポート」では、ITセキュリティ リーダーの62％が、組織内のすべてのアプリケーションについて把握している自信があまりないか、全くないと回答しています。

アプリケーション インベントリは、あらゆるアプリケーション戦略の最も基本的な要素です。これは、内部、横方向（他の政府機関など）、または外部（一般市民など）に提供されるあらゆるアプリケーションのカタログであり、以下のものが含まれます。

• アプリケーションまたはデジタル サービスが実行する機能の説明
• アプリケーションのオリジン（カスタム開発、パッケージ ソフトウェア、サードパーティ サービスなど）
• アプリケーションがアクセスまたは操作する必要がある主要なデータ要素
• アプリケーションが通信している他のサービス
• アプリケーションの一部であるオープンソースやその他のサードパーティ コンポーネント
• アプリケーションに責任を持つ個人またはグループ

アプリケーション インベントリを初めて構築するときは、多くの場合、骨の折れる、時間のかかる作業となります。不正なアプリケーションを簡単に排除する方法の1つは、アプリケーション インベントリを許可リストにすることです。単に許可リストにないアプリケーションが、企業リソース（ネットワークなど）にアクセスできないようにするだけです。社外のアプリケーションを追い詰めるには、クラウド アクセス セキュリティ ブローカー（CASB）のようなツールが非常に役に立ちます。CASBは、ユーザーとインターネットの間に位置し、すべてのアプリケーションの活動を監視して報告します。また、従業員がどのアプリケーションを最も多く使用しているか（そしてどのようにアクセスしているか）を把握できるだけでなく、シャドーITアプリケーションの使用状況も把握することができます。

DevOpsアーキテクチャ モデルを採用し、アプリケーションをそこに統合することで、今後のインベントリ プロセスを簡素化することができます。アプリケーションの優先順位が決定し、マルチクラウドまたはSaaS環境に配置されると、開発者はオープンソースのツール（Ansible、GitHubなど）を使用して導入をパッケージ化できます。導入は、セキュリティ サービス、パッチ管理、コードを含むこれらのツールによって管理されます。インベントリ情報は一元化され、迅速に提供することができます。したがって、アプリケーションはクラウドまたはSaaS環境内に存在する場合でも、組織が識別できます。

アプリケーション インベントリの正確性を確保するために費やす時間はすべて、FedRAMPシステムの境界を迅速に定義する能力に直接的な良い影響を与えます。また、認証機関から要求されたときに、アプリケーションのインフラストラクチャ、あるいはアプリケーションの個々のコンポーネントの責任者を迅速かつ正確に検索することができるようになります。

最後に、FedRAMPへの取り組みでは、この作業を継続的に、場合によっては年に1回以上行うことが要求されます。これは、どのようなアプリケーションやデータ リポジトリが使用されているかに注意を払い、ユーザーが何をする必要があるかを監視して、開発環境がどのように進化しているかを評価する、絶え間ないプロセスなのです。

要約：セキュリティ対策を決定する際には、各アプリケーションの個別のリスク レベルを確認し、適用されるすべてのコンプライアンスに関する検討事項と組み合わせます。

サイバーリスクは、米国政府内のITリーダーにとって重要な問題であり、懸念が高まっています。これに対処するには、まず、各アプリケーションのサイバー リスクを評価することから始める必要があります。

インベントリに含まれる各アプリケーションは、4つの主要なタイプのサイバー リスクを検証する必要があります。

1. 社内の機密情報（軍事機密など）の漏洩
2. 顧客/ユーザーの機密情報（人事記録、納税履歴など）の漏洩
3. データまたはアプリケーションの改ざん
4. データまたはアプリケーションへのサービス拒否

サイバーリスクでは、デジタル サービスの重要性は、上記のカテゴリごとに、サイバー攻撃からそのサービスが受ける経済的または評判への影響を考慮することによって測定する必要があります。組織によって、特定のサービスに対する潜在的な損失レベルは他と異なるため、各組織は定義されたミッションに基づいて独自の推定を行う必要があります。例えば、FISMAでは、ミッションまたはビジネス ケースに対する機関レベルのリスクを判断するように求めています。しかし、ミッションのコンプライアンス基準が必然的に深まる場合に備えて、アプリケーション レベルのリスクも検証しておくことが現実的である場合が多くなっています。

組織のリスク計算には、適用される規則、ガイドライン、および契約への非準拠のリスクも含まれる場合があります。連邦政府機関はルールや基準に囲まれており、アプリケーションやデジタル サービスを評価する際には、これらすべてを考慮する必要があります。サイバー リスクを評価するためのアプリケーションにリンクされたモデルを確立すれば、管理可能で適切なきめ細かいサービスのグループに境界を絞ることができるため、プロセスでFedRAMP準拠のCDM/ConMon要件を容易に満たすことができます。

SaaSサービスを利用することで、組織のコンプライアンスに関する懸念を軽減することができます。アプリケーションのリスクとコンプライアンスに関する懸念は、SaaSプロバイダが責任を負うことになります。これにより、組織はカスタム アプリケーションに集中することができます。

ユーザー アカウント、財務データ、個人情報を保護するために、アプリケーション内にクラウド セキュリティ サービスを統合することを検討します。クラウド セキュリティ サービスは、クライアントが悪意を持っているか、実際のユーザーであるかを判断するためにアプリケーションで使用できる数百万ものデータ ポイントを備えています。データ ポイントは継続的に更新されるため、新たな脅威を特定することができます。ルールはリアルタイムでアプリケーションに適用され、既存の企業のセキュリティ戦略と連動させることができます。

要約：組織に必要なアプリケーション サービス（アプリケーションをバックグラウンドで実行するソリューション）を特定します。

アプリケーションがスタンドアロンになることはめったにないため、アプリケーション インベントリとともに、アプリケーションを実行しているアプリケーション サービスを管理および追跡する必要があります。アプリケーション サービスは、アプリケーションのスピード、モビリティ、セキュリティ、および操作性を向上させるアプリケーション ビルダ向けのパッケージ ソリューションです。アプリケーション サービスは、アプリケーションのワークロードにいくつかの重要な利点をもたらします。

• スピード：アプリケーションのワークロードのパフォーマンスと、迅速に提供する能力。
• モビリティ：アプリケーションのワークロードを物理的または論理的なホスティング サイトから別のサイトに簡単に移動できること。
• セキュリティ：アプリケーションのワークロードとそれに関連するデータを保護すること。
• 操作性：アプリケーションのワークロードを簡単に導入でき、簡単に稼働状態を維持し、障害が発生しても簡単にトラブルシューティングできることを保証すること。

依存するアプリケーション サービスを見つける良い方法は、ご使用の環境のFISMAまたはFedRAMPシステム セキュリティ プランのコントロール セクションを調べることです。これによって、多くの場合、セキュリティに焦点を当てたアプリケーション サービスと、それに依存する他のサービスの両方が存在することが指摘されます。

すべてのアプリケーションはアプリケーション サービスの恩恵を受けることができますが、すべてのアプリケーションが同じアプリケーション サービスを必要とするわけではありません。

一般的なアプリケーション サービスは以下のとおりです。

• ロード バランシング
• DNSデリバリ
• グローバル サーバ ロード バランシング
• Web Application Firewall
• DDoS防止/保護
• アプリケーションの監視と分析
• アイデンティティとアクセスの管理
• アプリケーション認証
• APIゲートウェイ
• コンテナのイングレスおよびエグレス制御
• SSL暗号化

すべてのアプリケーション サービスには、直接的（サービス自体）にも間接的（運用維持）にも、ある程度のコストがかかります。優先度の低いアプリケーションは、共有機能を利用することでコストを削減できます。共有機能はセキュリティを提供し、パフォーマンスを維持します。高い価値を持つ資産は、組織の生産性にとって非常に重要であるため、より多くのリソースを必要とします。

注目すべき点は、多くのアプリケーションサービスが、狭いカテゴリのアプリケーションをサポートするために特別に設計されていることです。例えば、IoTアプリケーションを提供するために設計されたアプリケーションだけが、IoTゲートウェイを必要とします。従来のアーキテクチャで提供されるアプリケーションは、コンテナ化された環境をターゲットとするアプリケーションサービスを必要としないため、イングレス コントロールやサービス メッシュのアプリケーションサービスは適用できない場合があります。

場合によっては、コンプライアンスを確保するため、またはリスクを低減するために、新しいアプリケーション サービスを購入する必要があります。技術的にはコンプライアンス基準を満たすかもしれませんが、最小限のベースライン コントロールを選択する誘惑には常に抗い、サイバー リスクの対処能力を高めるアプリケーション サービスを選択することにこだわるべきです。

概要：アプリケーションをタイプ、優先順位、要件に基づいて論理的にグループ化します。

アプリケーション インベントリが完成したら、次のステップとして、異なる管理とアプリケーション サービスのアプローチを必要とする特性（機密データへのアクセス、より多くの脅威への暴露など）に基づき、アプリケーションを論理的なカテゴリにグループ化します。

分類したら、エンタープライズ アプリケーション ポリシーにより、アプリケーション自体の重要性と企業の分類に基づいて、さまざまなアプリケーション タイプに適用されるパフォーマンス、セキュリティ、およびコンプライアンス プロファイルを指定する必要があります。

まずは基本的な4つの層から始めることをお勧めします。

アプリケーションが直面する脅威は、それらがホストされている環境によって異なるため、この分類をさらに拡張して、導入環境（オンプレミス、パブリック クラウドなど）に基づいて差別化することができます。

この方法で目標に優先順位を付けると、適切なFISMA/FedRAMPレベルに導入するアプリケーションを簡単に事前分類するのにも役立ちます。ここで少し時間をかけてミッションの目標に合わせた構造を開発することで、後で監査人と話す時間を大幅に短縮できます。

許容できる時間枠で必要なあらゆることを行うのに十分なリソースがある組織はありません。アプリケーションに優先順位を付けることで、アプリケーション サービスで強化する必要のあるアプリケーション、モダナイズまたは置換する必要のあるアプリケーション、労力を払う価値のないアプリケーションにトリアージ アプローチをとることができます。後者のカテゴリのアプリケーションの場合は、ネットワーク内でセグメント化されていることを確認し、無害なIoTサーモスタットが大きなネットワーク侵害につながるシナリオを回避してください。このプロセスには、新しいバリュー ストリームを活用できるため、社内で開発するか、サードパーティから調達する必要のある新しいアプリケーションの検証も含まれます。

概要：導入と消費のパラメータを策定します。

IT戦略の基礎となるのは、常に導入と運用管理ですが、最新のエンタープライズ アプリケーション戦略には、いくつかの新しい要素が加わっています（エンドユーザー エクスペリエンスの重要性など）。これには、以下が含まれます。

• どのような導入アーキテクチャがサポートされるか（ハイブリッド クラウド、マルチクラウドなど）
• アプリケーション カテゴリごとの導入モデル オプション
• アプリケーションのアクセス ポイントになるパブリック クラウド
• パブリック クラウドのネイティブ サービスをどの程度活用できるのか（サードパーティと比較して）

アプリケーションによって、導入と消費モデルに関するニーズは異なります。アプリケーション戦略を策定するこの段階では、さまざまな導入オプションについて明確に理解するよう努める必要があります。それぞれの導入オプションには、異なる消費モデル、コストへの影響、コンプライアンス/認証プロファイルがある場合があります。

導入モデルを選択する際には、利用可能なスキルや人材のインベントリを作成して、決定に反映させることも賢明です。例えば、AWSを管理できる人材が社内におらず、契約ベースのスキルを利用できない場合にAWSでの導入を選択すると、スピードが遅くなり、リスクが生じる可能性があります。

FISMAであれFedRAMP ATO/P-ATOであれ、機関がミッションの基準として使用するいずれの場合でも、導入と管理のメカニズム自体が認可の対象となり得ることを決して忘れてはなりません。

要約：エンタープライズ アプリケーション戦略の各要素について、責任の所在を明確にします。

目標や優先順位を明確にすることに加え、エンタープライズ アプリケーション戦略には、役割と責任に関する要素も含める必要があります。

把握すべきこと：

• アプリケーション ポートフォリオの最適化とセキュリティ保護に関する決定権を持つのは誰か（テクノロジの選択、アプリケーションの処理、ユーザー アクセス管理など）。
• 各アプリケーションへの特権ユーザー アクセスを持つのは誰か。
• 各アプリケーションをさまざまな環境に導入し、運用、維持する責任を負うのは誰か。
• エンタープライズ アプリケーション ポリシーへの準拠に責任を負うのは誰か。
• エンタープライズ アプリケーション戦略の目標への準拠を監視するのは誰か。そして、その指標の報告先は誰か。
• オープン ソースやサードパーティのコンポーネント/サービス プロバイダを含むベンダーのコンプライアンスを監視するのは誰か。
• アプリケーションやサービスが変更され、追加・削除され続ける中で、すべてのアプリケーションとアプリケーション サービスが確実に考慮されるようにするのは誰か。

これらの責任は、個人、複数の部門からなる委員会、あるいは部門全体が負う可能性があります。いずれにせよ、これらの責任は明確に規定されなければなりません。実際、コンプライアンス体制が要求する定義よりも、さらに明確な定義が必要な場合があります。

より高度な組織では、運用プロセスと自動化を採用して、開発プロセスの初期段階、つまりアプリケーションの開始時にこれらの責任を割り当てることになります。重要な機能をサポートするアプリケーションが何百、何千と存在するマルチクラウド環境では、アプリケーション戦略とそれに対応するポリシーによって、責任の所在を明確にする必要があります。

エンタープライズ アプリケーション戦略を策定したら、その目的を果たすために、これを実施する必要があります。実施方法としては、プロセスの自動化（ユーザー アクセス制御、チェックイン時のコード脆弱性スキャンなど）に組み込まれた「ハード」なガードレールと、従業員のトレーニングや能力・意識の向上などの「ソフト」な対策が必要です。

アクセス制御ポリシーは、エンタープライズ アプリケーション戦略で定義された運用上の役割と責任をサポートし、オンプレミスとクラウドの両方にあるすべてのアプリケーションに適用される必要があります。特権ユーザー アクセスは、アプリケーションに対して管理者権限またはルート権限を持つため、高度なAPTの標的になるなど、アプリケーションに与えるリスクがあるため、特に注意する必要があります。

特権ユーザーに推奨される特別な対策は以下のとおりです。

• 特権ユーザーは、常に別のグループに分けなければなりません。これらのユーザーは、すべてのユーザーまたはアプリケーション分類層には実装しないセキュリティ管理を必要とするアクセス制御ソリューション内では「高リスク」と定義する必要があります。
• リモート認証では複数の要素を要求する必要があります。有効な認証情報を使用してアクセスが試みられたが、2つ目の認証要件が満たされなかった場合（認証情報が共有された侵害から有効な認証情報を攻撃者が収集した場合）、または前回の有効なログインから考えて物理的に不可能な場所からアクセス（東ヨーロッパでログインしようとしたユーザーが、2時間前に米国でログインに成功していたなど）が試みられた場合などは、追加のセキュリティ レビューが完了するまでそのアカウントをロックする必要があります。
• 管理者アクセスは、業務を遂行するためにこのレベルのアクセスを定期的に必要とする、訓練された適切な担当者のみに許可します。緊急時や特別なプロジェクトのために一時的に付与されるアクセス権は、このアクセス権を削除し忘れた場合にシステム管理者に通知する、自動使用監視機能を備えた別のユーザー グループに設定する必要があります。アクセス権の適切性のレビューは、利益相反を避けるため、アプリケーションの担当チーム、またはアプリケーションへのアクセス権を付与するチームから独立して定期的に実施する必要があります。特権ユーザーが長期間アカウントにアクセスしない場合、そのユーザーが本当にそのアクセス権を必要としているかどうかを検討する必要があります。
• アプリケーションに対するすべての特権ユーザー アクセスについて、適切な説明責任を記録する必要があります。これには、そのユーザー アカウントで行われたあらゆる変更が含まれます。

クラウド上でこのレベルの可視性と自動化を実現することは、一般的にこれらの機能はネイティブで利用できないため、困難でコストがかかる場合があります。しかし、サードパーティのライセンスを利用すれば可能であり、重要性を考慮すれば、投資する価値は十分にあります。

アプリケーションは着実に増加し、攻撃者はメディアから入手できる豊富なデータをもとに、どのアプリケーションを狙うか、誰がアクセスできるかを把握するため、セキュリティ意識向上トレーニングはこれまで以上に重要なものとなっています。

スピア フィッシングが攻撃者の手口である以上、フィッシングのトレーニングは大きく注目されるべきです。2018年のF5 Labsの「フィッシングおよび不正取引レポート」によると、従業員に10回以上トレーニングを行うことで、フィッシングの成功率を33％から13％に低減できることが分かっています。しかし、セキュリティ意識向上トレーニングが十分に、適切な教材で実施されることは稀です。コンプライアンス準拠を目的とした定型の意識向上トレーニングは、従業員が情報セキュリティにおける自分の役割を理解せず、また情報セキュリティに対する個人的な義務感も持てないというリスクをはらんでいます。侵害のリスクを減らすことを目的とするならば、組織に合わせてパーソナライズされたトレーニングを頻繁に実施する必要があります。

攻撃者にはダウンタイムはないため、従業員は常に警戒を怠らないようにしなければなりません。特に連邦政府や連邦政府に製品やサービスを提供している企業にとっては、疑問を持ち続けることがすべての組織の規範となります。従業員は、アプリケーションやデータへのアクセスによって自分が標的になることを認識する必要があります。また、そのアクセスやデータが敵対する国家によってどのように利用されるか、あるいは営利目的のサイバー犯罪者によってどのように販売されるか（それを競合他社が購入するか）についても理解する必要があります。

デジタル トランスフォーメーションを確実に成功させるためには、すべての組織がエンタープライズ アプリケーション戦略とそれに対応するポリシーを採用し、それらについて従業員をトレーニングする必要があります。レガシー、ハイブリッド、および最新のアプリケーションが混在する連邦政府機関では、これは特に重要です。信頼性が高く、安全で、権限のあるデジタル サービスの提供で成功を収めるには、これらが必要なのです。

アプリケーションは、あらゆる組織のデジタル トランスフォーメーションの要であり、ソフトウェアの開発・導入方法が急速に変化する中、組織価値の最大の源であると同時に脆弱性の最大の発生源でもあります。ここで説明したアプリケーション戦略とポリシーのコンポーネントは、あらゆる組織のデジタルの願望を保護するために不可欠な基盤を提供します。アプリケーション ポートフォリオのリスク プロファイルは日々増加の一途をたどっているため、組織は迅速に戦略とポリシーを形式化する必要があります。

¹ 行政管理予算局のクラウド スマート戦略

² F5 Labs：10年間の情報漏洩事件から得た教訓

³ 水槽をハッキングしてカジノのデータを盗む犯罪者、Forbes

⁴ 基本的なネットワーク セグメンテーション エラーが原因でTargetへの侵害が発生、ComputerWorld

⁵ 2018年のソフトウェア サプライ チェーンの現状、Sonatype