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

米国連邦政府機関の 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 の HVAC ベンダーの悪用から始まり、POS システムの侵害と 4,000 万枚のクレジットカードの紛失で終わりました。⁴

管理されていないまま放置すると、オープンソースやその他のサードパーティのコンポーネントやサービスもリスクをもたらす可能性があります。 Sonatype の「ソフトウェア サプライ チェーンの現状 2018」では、オープン ソース コンポーネントのダウンロードの 8 分の 1 に既知のセキュリティ脆弱性が含まれていることが報告されています。⁵ 公共部門を含む組織は、開発と提供をスピードアップできるため、オープンソースを活用しています。 しかし、これらの組織は、セキュリティ スキャンやレビュー プロセスにオープン ソース コンポーネントを含めないことがよくあります。 これらのコンポーネントはアプリケーション ポートフォリオの一部となり、カスタム コードと同じように慎重に扱う必要があります。 これには、サーバー側 (NPM パッケージ、ライブラリなど) とクライアント側の両方のコンポーネントが含まれます。

アプリケーションが組織の目標を達成する上でより重要な役割を果たすようになり、これらのアプリケーションの成長は、ほとんどの組織が業務を拡大する能力を上回っています。 境界にセキュリティを配置する従来のモデルは拡張性がなく、脅威を防ぐ効果も限られています。 ソフトターゲットが侵害されると、高価値の資産が危険にさらされます。 新しいアーキテクチャと展開モデルにより、従来のセキュリティ対策がさらに強化されます。 アプリは分散した場所にステージングされており、パフォーマンスを向上させるためにマルチクラウド アプリケーション サービスが使用されています。 一方、アプリケーションに関連する脅威の表面積は飛躍的に拡大しています。

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

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

事態が十分に複雑でないかのように、連邦政府機関は、柔軟性の向上、可用性の向上、ベンダー ロックインの削減、そして場合によってはコスト削減を実現するために、マルチクラウドと SaaS の導入に移行しています。 問題は、予算配分を超過することなく、ハイブリッド、マルチクラウド、SaaS アーキテクチャ全体で標準化された安全でシームレスなアプリケーション エクスペリエンスをどのように提供できるかということです。

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

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

マルチクラウドおよび SaaS アプリケーション サービス (アプリケーションの保護、管理、最適化のために導入されるソリューション) を標準化すると、マルチクラウド アーキテクチャに伴う運用上の複雑さが軽減されます。

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

クラウド生まれの組織の多くが IT 部門すら持たない時代において、従来の IT アーキテクチャと運用プロセスは、アプリケーション開発者や DevOps チームの期待に著しく応えられません。 アプリケーションをより早くリリースしたいという要望により、従来のネットワークおよびセキュリティ チーム、および関連するセキュリティおよび運用プロセスが省略されることがよくあります。 実際、エンタープライズ アプリケーション ポートフォリオの保護は、テクノロジーだけでなく、人材とプロセスにも大きく関係しています。

組織は、このマルチクラウドの広がり全体にわたってパフォーマンス、そしてさらに重要なリスクを管理するために、ソリューションを切実に求めています。 アプリケーションがどこに存在するかに関係なく、ソリューションは一貫したポリシーの導入をサポートし、脅威を管理し、可視性を提供し、アプリの健全性とパフォーマンスの監視を可能にする必要があります。 アプリケーション開発チームと DevOps チームの革新性と俊敏性が妨げられると、不適切なソリューションによってデジタル変革のメリットが簡単に減少してしまう可能性があります。

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

まとめ： この機会を利用して、連邦政府機関の使命と目標に沿ったエンタープライズ アプリケーション戦略を作成してください。

デジタル変革の目的は、扱いにくい手動のプロセスを、効率的でデータが豊富なアプリケーションに置き換えることです。 したがって、エンタープライズ アプリケーション戦略の包括的な目標は、ミッションの達成に関連する組織のデジタル機能を直接強化、高速化、保護することである必要があります。 この目標に一致しないアプリケーションまたは関連するアプリケーション サービスは、優先順位を下げる必要があります。 優先度の高いアプリケーションには追加のリソースとセキュリティを与える必要がありますが、優先度の低い資産では共有リソースを使用できます。

この調整は、現状を考慮することも意味し、これには現在の企業データ戦略、コンプライアンス要件、および組織の全体的なリスク プロファイルを注意深く検討することが含まれます。

多くの場合、これらのさまざまなソースによって課される制約と、それがアプリ開発チームの俊敏性に与える影響は十分に理解されていない可能性があります。 エンタープライズ アプリケーション戦略では、イノベーション、俊敏性、リスクという、しばしば競合する力の間で、組織が達成しようとしているバランスを明確にする必要があります。

まとめ： 最新化を開始する前に、完全なアプリケーション インベントリを構築する必要があります。

エンタープライズ アプリケーション戦略に関しては、ほとんどのチームは新たに始めるほど幸運ではありません。 IT 業界のほぼすべての人が、何十年にもわたって機能し続けるように調整されたレガシー システムの上に、さまざまなシステムが混在した結果生まれたテクノロジー アーキテクチャを継承しています。 この問題は、商業部門と比較すると、米国連邦政府内で特に深刻になる可能性があります。 これらの矛盾したテクノロジーを目的の状態にスムーズに移行することは、ほとんど容易ではありません。 したがって、さらなる発見と分析を行う必要があります。

非常に単純に聞こえるかもしれませんが、何かを適切に保護するには、まずそれが存在することを知り、次にその健全性を正確に監視できなければなりません。 しかし、いくつかの例外を除き、ほとんどの組織は、ポートフォリオ内のアプリケーションの数を自信を持って報告できず、それらのアプリケーションが正常で安全であるかどうかもわかりません。 F5 Labs 2018 アプリケーション保護レポートでは、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 プロバイダーの責任です。 これにより、組織はカスタム アプリケーションに集中できるようになります。

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

まとめ： 組織に必要なアプリケーション サービス (バックグラウンドでアプリケーションを実行するソリューション) を評価します。

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

• スピード： アプリケーション ワークロードのパフォーマンスと迅速な配信能力。
• モビリティ: アプリケーション ワークロードを 1 つの物理ホスティング サイトまたは論理ホスティング サイトから別のサイトに簡単に移動できます。
• 安全： アプリケーション ワークロードとそれに関連するデータの保護。
• 操作性: アプリケーション ワークロードの展開が容易で、実行を継続しやすく、障害が発生した場合のトラブルシューティングが容易であることを保証します。

依存するアプリケーション サービスを見つける良い方法は、環境の FISMA または FedRAMP システム セキュリティ プランのコントロール セクションを調べることです。 これにより、セキュリティに重点を置いたアプリケーション サービスと、それらに依存するその他のサービスの両方の存在が明らかになることがよくあります。 

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

一般的なアプリケーション サービスには次のものがあります。

• 負荷分散
• DNS配信
• グローバル サーバー負荷分散
• ウェブアプリケーションファイアウォール
• DDoS 防止/保護
• アプリケーションの監視と分析
• アイデンティティとアクセス管理
• アプリケーション認証
• APIゲートウェイ
• コンテナの出入り制御
• SSL暗号化

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

多くのアプリ サービスは、特に狭いカテゴリのアプリケーションをサポートするように設計されていることに注意してください。 たとえば、IoT アプリを提供するように設計されたアプリケーションにのみ IoT ゲートウェイが必要です。 従来のアーキテクチャで配信されるアプリケーションでは、コンテナ化された環境を対象とするアプリ サービスが必要ないため、イングレス制御やサービス メッシュ アプリケーション サービスは適用できない可能性があります。

場合によっては、コンプライアンスを確保したりリスクを軽減したりするために、新しいアプリケーション サービスを取得する必要があることがあります。 技術的にはコンプライアンス基準を満たしているかもしれませんが、最低限のベースライン制御を選択したいという誘惑に常に抵抗し、サイバーリスクに対処する能力を強化するアプリケーション サービスを選択するようにする必要があります。

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

アプリケーション インベントリが完了したら、次のステップは、異なる管理およびアプリケーション サービス アプローチを必要とする特性 (機密データへのアクセス、より多くの脅威への露出など) に基づいて、アプリケーションを論理カテゴリにグループ化することです。

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

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

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

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

許容できる時間枠内で望むことをすべて実行できるだけのリソースを持つ組織はありません。 アプリケーションに優先順位を付けることにより、アプリケーション サービスで強化する必要があるアプリ、最新化または置換する必要があるアプリ、労力に見合わないアプリをトリアージ アプローチで判断できます。 後者のカテゴリのアプリについては、ネットワーク内で確実にセグメント化して、無害な IoT サーモスタットがネットワーク全体の侵害につながるようなシナリオを回避してください。 このプロセスには、新しいバリュー ストリームを生み出す可能性のある新しいアプリケーションの検討も含まれており、そのようなアプリケーションは社内で開発するか、サードパーティから調達する必要があります。

まとめ： 展開および消費パラメータを開発します。

あらゆる IT 戦略の基盤となる部分は常に導入と運用管理であり、最新のエンタープライズ アプリケーション戦略では、いくつかの新しい工夫 (エンド ユーザー エクスペリエンスの重要性など) が加えられています。 これには次の点の確認が含まれます。

• サポートされているデプロイメント アーキテクチャ (例: ハイブリッド クラウド、マルチクラウド)
• 各アプリケーションカテゴリの展開モデルオプション
• どのパブリッククラウドがアプリケーションのアクセスポイントとして機能できるか
• パブリッククラウドネイティブサービスはサードパーティと比べてどの程度活用できるか

アプリケーションによって、展開および消費モデルに関するニーズは異なります。 アプリケーション戦略を開発するこのフェーズでは、さまざまな展開オプションを明確に理解するように努める必要があります。各展開オプションには、異なる消費モデル、コストの影響、コンプライアンス/認証プロファイルがある可能性があります。

展開モデルを選択する際には、決定の要素として利用可能なスキルと人材をリストアップすることも賢明です。 たとえば、社内に管理できる人材が不足しており、契約ベースのスキルにアクセスできない場合に AWS へのデプロイを選択すると、速度が低下し、リスクが生じる可能性があります。

導入および管理メカニズム自体が、FISMA または FedRAMP ATO/P-ATO のいずれに基づいているかにかかわらず、機関がミッションの標準として使用するかどうかにかかわらず、承認の対象となる可能性があることを決して忘れないでください。

まとめ： エンタープライズ アプリケーション戦略の各要素に対して明確な責任の所在を確立します。

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

知っておくべきこと：

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

これらの責任は、個人、複数部門の委員会、あるいは部門全体に及ぶ可能性があります。 いずれにせよ、それらは明確に説明されるべきです。 実際のところ、コンプライアンス体制で求められる定義よりもさらに詳細な定義が必要になる場合があります。

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

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

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

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

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

クラウドでのアクセス制御に関してこのレベルの可視性と自動化を実現することは、これらの機能が通常ネイティブでは利用できないため、困難でコストがかかる可能性があります。 ただし、サードパーティのライセンスでは可能であり、その重要性を考えると、投資する価値は十分にあります。

アプリケーションが着実に増加し、攻撃者がどのアプリケーションをターゲットにし、誰がそのアプリケーションにアクセスできるかを判断するために使用するメディア内のデータが豊富にあるため、セキュリティ意識向上トレーニングがこれまで以上に重要になっています。

スピアフィッシングは攻撃者の手口であるため、フィッシングのトレーニングに重点を置く必要があります。 2018 F5 Labs フィッシングおよび詐欺レポートによると、従業員を 10 回以上トレーニングすると、フィッシングの成功率が 33% から 13% に低下することがわかりました。 しかし、セキュリティ意識向上トレーニングが適切な教材を使って十分に実施されることはほとんどありません。 コンプライアンスの要件を満たすように設計された、既成の意識啓発トレーニング サービスでは、従業員が情報セキュリティにおける自分の役割を理解しておらず、それに対する個人的な義務感も持たないというリスクがあります。 違反のリスクを軽減することが目的であれば、組織に合わせてカスタマイズされた頻繁なトレーニングが効果的です。

攻撃者にはダウンタイムがないため、従業員は常に警戒を怠ってはなりません。 継続的な好奇心の文化は、すべての組織、特に連邦政府機関や連邦政府に製品やサービスを提供している企業にとって標準となるべきです。 従業員は、アプリケーションやデータにアクセスできるため、攻撃の標的になる可能性があることを認識する必要があります。 また、そのアクセスやデータが敵対国家によってどのように使用されるか、または営利目的のサイバー犯罪者によってどのように販売されるか（そしてそれが敵対者によって購入されるか）についても認識しておく必要があります。

デジタル変革を成功させるには、すべての組織がエンタープライズ アプリケーション戦略と対応するポリシーを採用し、従業員にトレーニングを行う必要があります。 レガシー、ハイブリッド、最新のアプリケーションが多数混在する連邦政府の領域では、これが特に重要です。 信頼性が高く、安全で、認可されたデジタル サービスを成功裏に提供するには、これが必要です。

アプリケーションはあらゆる組織のデジタル変革の中心であり、ソフトウェアの開発および展開方法が急速に変化しているため、組織にとって最大の価値の源であると同時に、最大の脆弱性の源でもあります。 ここで概説したアプリケーション戦略とポリシーのコンポーネントは、あらゆる組織のデジタル化の目標を守るための重要な基盤を提供します。 アプリケーション ポートフォリオのリスク プロファイルは日々増大する一方であるため、組織は迅速に行動して戦略とポリシーを正式化する必要があります。

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

² F5ラボ: 10年間のデータ侵害から学んだ教訓

³ 犯罪者が水槽をハッキングしてカジノからデータを盗む、フォーブス

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

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