すべての連邦政府機関にエンタープライズアプリケーション戦略が必要な理由と、その策定方法
はじめに
米国連邦政府機関のIT幹部には、無駄を削減し、サイバー攻撃による損失を最小限に抑えながら、より大きな価値を提供するという難しいかじ取りが求められます。一方では、最新テクノロジーを取り入れて効率を高め、より大きな価値を提供し、納税者の負担を軽減する必要があります。他方では、変化し続け、拡大する脅威環境に直面しており、その緩和には多大なリソースが必要です。つまり、あらゆる取り組みと意思決定において、イノベーションと保護を両立させなければなりません。一見相反するこれらの目標を達成するため、連邦政府機関のITリーダーは、組織の使命に合わせたエンタープライズアプリケーション戦略を策定することが重要です。
アプリケーション時代の幕開け
「F5 2019 State of Application Services」レポートの調査回答者の65%が、自社はデジタルトランスフォーメーションの途上にあると回答しています。デジタルトランスフォーメーションとは、組織がテクノロジーを活用して、パフォーマンスとユーザーの生産性を大幅に向上させる新たなアプローチです。
つまり、アプリケーションそのものがビジネスやミッションになりつつあります。
この抜本的な変化を活かすため、組織は次のような新しいビジネスモデルやIT運用モデルを追求し、大規模な変革を進めています。
- クラウドベースのメールや生産性向上ツールなどのSaaSサービスを活用
- カスタムアプリケーションをコンテナ化し、管理を簡素化してコストを削減
- クラウドセキュリティサービスを使用して攻撃を迅速に特定し、組織のルールに応じてポリシーを適用する
アプリケーションは、さまざまな種類のデバイスに配信されています。アプリケーションにアクセスするユーザーは、従来の企業環境内にいるとは限らず、モバイル環境や自宅から業務を行っています。CRMやERPをはじめとするビジネスクリティカルな機能を提供するには、従来の企業ネットワーク外からのアクセスを可能にする必要があります。
The 2018 F5 Labs Application Protection Reportによると、公共部門の組織では平均680のアプリケーションが使用されており、そのうち32%がミッションクリティカルと見なされています。
アプリケーションが急増する中、組織はそれらを新たなアーキテクチャやサービスに導入しています。2019年版「State of Application Services」の調査によると、調査対象組織の14%がコンテナをアプリケーションワークロード分離の標準的な手法として採用し、回答者の87%がマルチクラウドアーキテクチャを導入しています。米国行政管理予算局（OMB）も、安全でセキュアなクラウドネットワークへの移行に向けて「Cloud Smart Strategy」を提唱しています1 。
急速に拡大する脅威対象領域を把握する
テクノロジーを活用して障壁を減らし、新たなサービスを提供し、価値を高めているのは、政府機関や民間企業だけではありません。サイバー犯罪者、武装組織、国家を背景とする脅威アクターも、驚異的な速さでサイバー攻撃能力を進化させています。ネットワークやインフラストラクチャの保護が強化されるにつれ、サイバー攻撃者はより脆弱な標的へと狙いを移しています。
ソフトターゲットは、職員情報や機密情報が保存されている可能性のある高価値資産への侵入に利用されます。F5 Labsの調査によると、サイバー攻撃者の86%は、アプリケーションを直接標的にするか、通常はフィッシングによってユーザーIDを窃取しています。2
攻撃者は、間接的に攻撃する方が容易な場合があることを学んでいます。その手口の1つは、IoTデバイスなど、重要度の低いアプリケーションを狙い、アクセス権限を段階的に高めることです。実際、犯罪者が米国のカジノのロビーにある水槽の温度計をハッキングし、それを足掛かりにして高額賭博客のデータベースに侵入した事例があります。3 同様に、甚大な被害をもたらした2013年のTargetの情報漏えいは、TargetのHVACベンダーを悪用した攻撃に端を発し、最終的にはPOSシステムが侵害され、4,000万件のクレジットカード情報が流出しました。4
オープンソースをはじめとするサードパーティ製のコンポーネントやサービスも、管理されていないとリスクをもたらす可能性があります。『Sonatype State of the Software Supply Chain 2018』によると、ダウンロードされるオープンソースコンポーネントの8件に1件に、既知のセキュリティ脆弱性が含まれています。5 公共部門を含む組織は、開発とデリバリーを迅速化できるため、オープンソースを活用しています。しかし、そのような組織では、セキュリティスキャンやレビュープロセスの対象にオープンソースコンポーネントを含めていないことが少なくありません。これらのコンポーネントはアプリケーションポートフォリオの一部となるため、カスタムコードと同様に厳密に精査する必要があります。これには、サーバー側のコンポーネント（NPMパッケージやライブラリなど）とクライアント側のコンポーネントの両方が含まれます。
組織の目標達成においてアプリケーションがこれまで以上に重要な役割を担うようになる一方、その増加のペースに、多くの組織の運用拡張能力が追いついていません。境界でセキュリティを確保する従来のモデルは拡張性に乏しく、脅威を防止する効果にも限界があります。攻撃を受けやすい標的が侵害されると、価値の高い資産がリスクにさらされます。新たなアーキテクチャや導入モデルも、従来のセキュリティ対策にさらなる課題をもたらしています。アプリケーションは分散した場所に配置され、パフォーマンス向上のためにマルチクラウドのアプリケーションサービスを利用しています。その一方で、アプリケーションに関連する攻撃対象領域は急激に拡大しています。
アプリケーションや攻撃を受けやすい対象の近くで継続的に監視することは、パフォーマンスを維持しながらセキュリティを確保するうえで重要です。インテリジェントなクラウドセキュリティを統合することで、アプリケーションと連携して脅威を迅速に緩和し、機密データを保護できます。少量のデータをクラウドに送信し、クラウド内に保存された数百万件のアーティファクトと比較することで、潜在的な脅威を特定できます。これにより、クライアントがボットか実際のユーザーかを判別できます。
A 不正行為低減サービスは、アプリケーションと連携して悪意のある攻撃者とやり取りすることで、より多くの種類のデータを取得し、大規模な不正行為を防止できます。完全な不正プロファイルを組織の継続的監視システムに送信することで、対策の実施、攻撃拡大の防止、侵害されたシステムの場所の特定、感染したマシンから脅威を除去する手順の提示が可能になります。アナリストは、詳細な分析のためにこの情報を運用部門に提供できます。
マルチクラウドとSaaSを有効活用
複雑さが増すなか、連邦政府機関は、柔軟性と可用性の向上、ベンダーロックインの軽減、さらに場合によってはコスト削減を図るため、マルチクラウドおよびSaaS環境への移行を進めています。課題は、割り当てられた予算を超えることなく、ハイブリッド、マルチクラウド、SaaSの各アーキテクチャ全体で、標準化されたセキュアでシームレスなアプリケーションエクスペリエンスをどのように提供するかです。
政府機関は、SaaSおよびマルチクラウド環境への接続を保護するため、Trusted Internet Connection（TIC）ポイントで境界セキュリティソリューションを使用する場合があります。しかし、接続ポイントが限られているため、パフォーマンス上の問題が生じる可能性があります。外部公開アプリケーションのトラフィックは、セキュリティ確保のためにこれらのポイントを経由する必要があり、遅延が発生します。セキュリティ確保のためにトラフィックを「トロンボーン」させる必要があるため、スケーラブルで高性能なアプリケーションのメリットが失われます。
境界型ソリューションも静的シグネチャに依存しています。新たな脅威が出現し、セキュリティクラウドプロバイダー内でそのプロファイリングが完了していても、その情報は境界システムに伝達されないため、攻撃を防ぐことができません。シグネチャの更新には1日から1週間かかる場合があります。シグネチャが作成され、境界セキュリティシステムに反映されるまでに、重要な資産が侵害される可能性があります。
アプリケーションサービスの標準化
アプリケーションのセキュリティ確保、管理、最適化のために導入するマルチクラウドおよびSaaSのアプリケーションサービスを標準化することで、マルチクラウドアーキテクチャに伴う運用の複雑さを軽減できます。
たとえば、ベンダー固有のメッセージキューイングサービスを使用しなければならないような、特定のプラットフォームに依存するサービスよりも、コードによるAPIの呼び出しやイベント駆動型システムなど、エンタープライズアプリケーションレベルで機能するサービスの方が、管理しやすく、より強力です。すべてのアプリケーションで共通の機能セットを有効にすることで、運用上のオーバーヘッドを削減できます。できるだけ多くのアプリケーションサービスに標準プラットフォームを採用することで、組織は自動化をさらに活用し、より多くのコードを再利用して、一貫性と予測可能性、再現性のある運用プロセスを実現できます。
エンタープライズアプリケーション戦略の策定
クラウドネイティブ企業の多くがIT部門すら持たない時代において、従来のITアーキテクチャと運用プロセスは、アプリケーション開発者やDevOpsチームの期待に十分応えられなくなっています。アプリケーションをより迅速にリリースしようとするあまり、従来のネットワークチームやセキュリティチームだけでなく、関連するセキュリティおよび運用プロセスまで省略されることも少なくありません。実際、企業のアプリケーションポートフォリオを保護するには、テクノロジーと同様に、人材とプロセスも重要です。
このように拡大したマルチクラウド環境全体でパフォーマンスを管理し、さらに重要なリスクを管理するために、組織は有効なソリューションを切実に求めています。アプリケーションがどこに存在していても、一貫したポリシーの適用、脅威の管理、可視性の確保に対応し、アプリケーションの健全性とパフォーマンスを監視できるソリューションが必要です。適合しないソリューションを導入すると、アプリケーション開発チームやDevOpsチームの革新性と俊敏性が損なわれ、デジタルトランスフォーメーションのメリットが容易に失われかねません。
アプリケーションの価値とリスクがともに高まる中、すべての連邦政府機関は、エンタープライズポートフォリオ内のアプリケーションをどのように構築または調達し、導入、管理、保護するかを定めたエンタープライズアプリケーション戦略を策定する必要があります。
ステップ0：アプリケーション戦略の目標を組織のミッションに整合させる
要約：この機会を活用し、連邦政府機関の使命と目標に沿ったエンタープライズアプリケーション戦略を策定します。
デジタルトランスフォーメーションの本質は、扱いにくい手作業のプロセスを、効率的で豊富なデータを活用できるアプリケーションに置き換えることです。したがって、エンタープライズアプリケーション戦略では、組織が使命を果たすために必要なデジタル能力を直接強化し、迅速化するとともに、保護することを最上位の目標とすべきです。この目標に合致しないアプリケーションや関連するアプリケーションサービスは、優先度を下げる必要があります。優先度の高いアプリケーションには追加のリソースとセキュリティ対策を割り当て、優先度を下げた資産には共有リソースを使用できます。
この整合性を確保するには、現状も考慮する必要があります。具体的には、現在のエンタープライズデータ戦略、コンプライアンス要件、組織全体のリスクプロファイルを慎重に検討します。
多くの場合、こうしたさまざまな要因による制約や、それらがアプリ開発チームのアジリティに及ぼす影響は、十分に理解されていない可能性があります。エンタープライズアプリケーション戦略では、イノベーション、アジリティ、リスクという、しばしば相反する要素の間で、組織としてどのようなバランスを取るのかを明確にする必要があります。
ステップ1：アプリケーションインベントリを作成する
要約：モダナイゼーションを開始する前に、完全なアプリケーションインベントリを作成する必要があります。
エンタープライズアプリケーション戦略に取り組む際、まったく新しい状態から始められるチームはほとんどありません。IT業界では、何とか稼働を維持してきたレガシーシステムの上に、数十年にわたって異種システムを継ぎ足した結果として形成されたテクノロジーアーキテクチャを、ほぼ誰もが引き継ぐことになります。この問題は、民間部門と比べて米国連邦政府で特に深刻になる場合があります。こうした整合性のないテクノロジーを、目標とする状態へ円滑に移行するのは容易ではありません。そのため、さらなる調査と分析が必要です。
あまりに単純な話に聞こえるかもしれませんが、何かを適切に保護するには、まずその存在を把握し、次にその健全性を正確に監視できなければなりません。しかし、ほとんどの組織は、保有するアプリケーションの数を確信を持って報告できず、それらのアプリケーションが健全かつセキュアであるかどうかとなるとなおさらです。F5 Labs 2018年アプリケーション保護レポートによると、ITセキュリティリーダーの62%は、組織内のすべてのアプリケーションを把握していることに、ほとんど、またはまったく自信がないことが明らかになりました。
アプリケーションインベントリに含める項目
アプリケーションインベントリは、あらゆるアプリケーション戦略の最も基本的な要素です。これは、内部向け、横断的（他の政府機関など）、外部向け（一般市民など）のいずれに提供されるかを問わず、すべてのアプリケーションを網羅し、以下の情報を含む一覧です。
- アプリケーションまたはデジタルサービスが果たす機能の説明
- アプリケーションの提供元（例：カスタム開発、パッケージソフトウェア、サードパーティサービス）
- アプリケーションがアクセスまたは操作する必要のある主要なデータ要素
- アプリケーションが通信しているその他のサービス
- アプリケーションを構成するオープンソースおよびその他のサードパーティ製コンポーネント
- アプリケーションに対して説明責任を負う個人またはグループ
インベントリの作成方法
アプリケーションインベントリを初めて作成する作業には、多くの場合、手間と時間がかかります。不正なアプリケーションを容易に洗い出す方法の1つは、アプリケーションインベントリを許可リストとして使用することです。許可リストにないアプリケーションは、ネットワークなどの企業リソースにアクセスできません。組織外で利用されているアプリケーションを特定するには、クラウドアクセスセキュリティブローカー（CASB）などのツールが非常に役立ちます。CASBはユーザーとインターネットの間に配置され、すべてのアプリケーションアクティビティを監視してレポートします。従業員が最もよく使用するアプリケーションとそのアクセス方法を把握できるだけでなく、シャドーITアプリケーションの利用状況に関するインサイトも得られます。
DevOpsアーキテクチャモデルを採用し、アプリケーションを統合することで、今後のインベントリ管理プロセスを簡素化できます。アプリケーションの優先度を決定し、マルチクラウドまたはSaaS環境に配置した後、開発者はオープンソースツール（Ansible、GitHubなど）を使用してデプロイをパッケージ化できます。その後、セキュリティサービス、パッチ管理、コードを含むデプロイは、これらのツールによって管理されます。インベントリ情報が一元化されるため、迅速に提供できます。これにより、アプリケーションがクラウドまたはSaaS環境に存在していても、組織はそのアプリケーションを識別できます。
FedRAMPに関する考慮事項
アプリケーションインベントリの正確性を確保するために費やす時間は、FedRAMPのシステム境界を迅速に定義する能力の向上に直結します。また、認証機関から求められた際に、アプリケーションのインフラストラクチャ、さらにはアプリケーションを構成する個々のコンポーネントの責任者を、より正確かつ迅速に特定できるようになります。
最後に、FedRAMPへの取り組みでは、この作業を継続的に、場合によっては年に複数回実施する必要があります。これは、使用されているアプリケーションとデータリポジトリを把握し、ユーザーに必要な作業を確認するとともに、開発環境がどのように変化しているかを評価する継続的なプロセスです。
ステップ2：各アプリケーションのサイバーリスクを評価
概要：セキュリティ対策を決定する際は、各アプリケーションの個別のリスクレベルを確認し、該当するすべてのコンプライアンス要件を併せて考慮します。
サイバーリスクは、米国政府機関のITリーダーにとって、深刻さを増す重大な懸念事項です。その対策として、まず各アプリケーションのサイバーリスクを評価する必要があります。
インベントリ内の各アプリケーションについて、主に次の4種類のサイバーリスクを評価する必要があります。
- 機密性の高い内部情報（軍事機密など）の漏えい
- 機密性の高い顧客／ユーザー情報（人事記録、納税履歴など）の漏えい
- データまたはアプリケーションの改ざん
- データまたはアプリケーションに対するサービス拒否
サイバーリスクの観点では、デジタルサービスの重要性は、上記のカテゴリーに従い、サイバー攻撃がそのサービスにもたらす財務上または評判上の影響を考慮して評価する必要があります。サービスごとの潜在的な損失の程度は組織によって異なるため、各組織は定められたミッションに基づいて独自に見積もる必要があります。たとえばFISMAでは、ミッションまたはビジネスケースに対する機関レベルのリスクを判断することが求められます。一方、ミッションに適用されるコンプライアンス基準が今後さらに厳格化する場合に備え、アプリケーションレベルでもリスクを検討しておくことが、多くの場合に実用的です。
コンプライアンスに関する考慮事項
組織のリスクを算定する際には、適用される規則、ガイドライン、契約に違反するリスクが含まれる場合があります。連邦政府機関には数多くの規制や標準が適用されるため、アプリケーションやデジタルサービスを評価する際には、そのすべてを考慮する必要があります。サイバーリスクを評価するためのアプリケーション連携型モデルを確立すると、対象範囲を管理可能かつ適切な粒度のサービス群に絞り込めるため、FedRAMPコンプライアンスに関するCDM/ConMon要件への対応が容易になります。
SaaSによるコンプライアンス対応の簡素化
SaaSサービスを利用することで、組織のコンプライアンスに関する懸念を軽減できます。アプリケーションのリスクとコンプライアンスに関する懸念には、SaaSプロバイダーが責任を負います。これにより、組織はカスタムアプリケーションに注力できます。
ユーザーアカウント、財務データ、個人情報を保護するため、アプリケーションへのクラウドセキュリティサービスの統合を検討してください。クラウドセキュリティサービスには数百万件のデータポイントがあり、アプリケーションはこれらを利用して、クライアントが悪意のある存在か正規ユーザーかを判断できます。データポイントは継続的に更新されるため、新たな脅威を特定できます。アプリケーションにはルールをリアルタイムで適用でき、既存のエンタープライズセキュリティ戦略と連携させることもできます。
ステップ3：必要なアプリケーションサービスを特定する
概要：アプリケーションをバックグラウンドで稼働させるソリューションであるアプリケーションサービスのうち、組織に必要なものを把握します。
アプリケーションが単独で稼働することはほとんどありません。そのため、アプリケーションのインベントリに加えて、アプリケーションを稼働させるアプリケーションサービスも管理し、追跡する必要があります。アプリケーションサービスは、アプリケーションの速度、モビリティ、セキュリティ、運用性を向上させる、アプリケーション開発者向けのパッケージソリューションです。アプリケーションサービスは、アプリケーションワークロードに次のような重要なメリットをもたらします。
- スピード：アプリケーションワークロードのパフォーマンスと、迅速に提供できる能力。
- モビリティ：アプリケーションワークロードを、ある物理または論理ホスティングサイトから別のサイトへ容易に移動できること。
- セキュリティ：アプリケーションワークロードと、それに関連するデータの保護。
- 運用性：アプリケーションワークロードを容易にデプロイして稼働を維持でき、障害発生時にも容易にトラブルシューティングできることを保証します。
依存関係にあるアプリケーションサービスを特定するには、ご利用の環境のFISMAまたはFedRAMPシステムセキュリティ計画にある［Controls］セクションを確認するのが効果的です。多くの場合、セキュリティに重点を置いたアプリケーションサービスと、それらに依存するその他のサービスの両方を把握できます。
すべてのアプリケーションがアプリケーションサービスのメリットを得られますが、必要とするアプリケーションサービスはアプリケーションごとに異なります。
一般的なアプリケーションサービスには、次のものがあります。
- 負荷分散
- DNS配信
- グローバルサーバーロードバランシング
- Webアプリケーションファイアウォール
- DDoSの防止／保護
- アプリケーションの監視と分析
- アイデンティティおよびアクセス管理
- アプリケーション認証
- APIゲートウェイ
- コンテナのイングレスおよびエグレス制御
- SSL暗号化
コスト、セキュリティ、パフォーマンスのバランス
すべてのアプリケーションサービスには、サービス自体にかかる直接的なコストと、運用・保守にかかる間接的なコストが一定程度発生します。優先度の低いアプリケーションでは、共有機能を利用することでコストを削減できます。共有機能は、セキュリティを確保しながらパフォーマンスを維持します。価値の高い資産は組織の生産性にとって非常に重要であるため、より多くのリソースが必要です。
多くのアプリサービスは、特定の限られた種類のアプリケーションをサポートするように設計されている点に留意する必要があります。たとえば、IoTアプリを提供するように設計されたアプリケーションにのみ、IoTゲートウェイが必要です。従来型のアーキテクチャで提供されるアプリケーションには、コンテナ化された環境を対象とするアプリサービスは必要ないため、イングレス制御やサービスメッシュのアプリケーションサービスは適用できない場合があります。
場合によっては、コンプライアンスを確保したり、リスクを軽減したりするために、新たなアプリケーションサービスの導入が必要になることがあります。最低限のベースライン制御でも技術的にはコンプライアンス基準を満たせる場合がありますが、それだけで済ませず、サイバーリスクへの対応能力を高めるアプリケーションサービスを選択することが重要です。
ステップ4：アプリケーションカテゴリーを定義する
概要：アプリケーションを種類、優先度、要件に基づいて論理的にグループ化します。
アプリケーションの棚卸しが完了したら、次に、異なる管理手法やアプリケーションサービスのアプローチが必要となる特性（機密データへのアクセス、より多くの脅威にさらされる可能性など）に基づいて、アプリケーションを論理的なカテゴリに分類します。
分類が完了したら、エンタープライズアプリケーションポリシーで、アプリケーション自体の重要度と社内分類に基づき、アプリケーションの種類ごとに適用するパフォーマンス、セキュリティ、コンプライアンスの各プロファイルを指定する必要があります。
まずは4つの基本階層から始めることを推奨します。
Tier 1
アプリケーションの特性
機密データを収集・変換するミッションクリティカルなデジタルサービスであり、高価値資産とみなされるアプリケーション
必要なアプリケーションサービス
負荷分散、グローバルサーバー負荷分散、Webアプリケーションファイアウォール、DDoS攻撃の防御／防止、ボット検知、SSLの暗号化と復号、ユーザーIDおよびアクセス管理、アプリケーション／サービスのIDおよび認証、アプリケーションの可視化／監視
その他の特性
アプリケーションサービスはアプリケーションの近くに配置され、アプリケーションのデプロイに組み込まれます。インテリジェントなクラウドサービスを使用して、ユーザーアカウント、クレジットカード情報、個人情報などの機密データを保護します。
Tier 2
アプリケーションの特性
機密データへのアクセスを提供するミッションクリティカルなデジタルサービス
必要なアプリケーションサービス
負荷分散、グローバルサーバー負荷分散、Webアプリケーションファイアウォール、DDoS対策／防御、ボット検知、SSL暗号化／復号、ユーザーIDおよびアクセス管理、アプリケーション／サービスのIDおよび認証、アプリケーションの可視化／監視
その他の特性
インテリジェントなクラウドサービスを使用して、ユーザーアカウント、クレジットカード情報、個人情報などの機密データを保護します。
Tier 3
アプリケーションの特性
機密データを収集せず、機密データへのアクセスも提供しないミッションクリティカルなデジタルサービス
必要なアプリケーションサービス
負荷分散、グローバルサーバー負荷分散、DDoS対策／防御、アプリケーションの可視化／監視
その他の特性
共有サービスを利用することで、コスト削減に役立てることができます。インテリジェントなクラウドサービスを使用して、ユーザーアカウント、クレジットカード情報、個人情報などの機密データを保護します。
Tier 4
アプリケーションの特性
その他のデジタルサービス
必要なアプリケーションサービス
負荷分散、アプリケーションの可視化／監視
その他の特性
共有サービスを利用することで、コスト削減に役立ちます。
分類がもたらす価値
アプリケーションが直面する脅威はホストされる環境によって異なるため、この分類をさらに拡張し、デプロイ環境（オンプレミス、パブリッククラウドなど）に基づいて区別できます。
このように目標に優先順位を付けることで、デプロイするアプリケーションを適切なFISMA/FedRAMPレベルにあらかじめ容易に分類できます。この段階で少し時間をかけてミッション目標を体系化しておけば、後で監査人との協議に費やす時間を大幅に削減できます。
どの組織にも、望むことをすべて許容可能な期間内に実現できるほどのリソースはありません。アプリケーションに優先順位を付けることで、アプリケーションサービスによる強化が必要なもの、モダナイズまたは置き換えるべきもの、労力をかける価値がないものを選別できます。最後のカテゴリーに該当するアプリケーションは、ネットワーク内で確実にセグメント化し、無害に見えるIoTサーモスタットがネットワーク全体への侵害につながる事態を回避してください。このプロセスには、新たな価値創出の機会をもたらす可能性があり、社内で開発するかサードパーティーから調達すべき新しいアプリケーションの検討も含まれます。
ステップ5：アプリケーションのデプロイと管理に関するパラメーターを定義する
概要：デプロイと利用に関するパラメーターを策定します。
導入と運用管理は、常にあらゆるIT戦略の基盤となってきました。最新のエンタープライズアプリケーション戦略では、エンドユーザー体験の重要性など、新たな観点も加わります。検討事項は次のとおりです。
- サポートされるデプロイアーキテクチャ（ハイブリッドクラウド、マルチクラウドなど）
- 各アプリケーションカテゴリーで選択可能な導入モデル
- アプリケーションのアクセスポイントとして利用できるパブリッククラウド
- サードパーティ製サービスと比較して、パブリッククラウドのネイティブサービスをどの程度活用できるか
アプリケーションによって、必要となる導入モデルや利用モデルは異なります。アプリケーション戦略を策定するこの段階では、利用モデル、コストへの影響、コンプライアンス／認証の特性がそれぞれ異なる可能性がある各種導入オプションについて、明確に把握することが重要です。
導入モデルを選択する際には、利用可能なスキルや人材を把握し、判断材料に加えることも重要です。たとえば、AWSを管理できる社内人材が不足し、外部の専門人材も確保できない状況でAWSへの導入を選択すると、進行が遅れ、リスクが生じる可能性があります。
導入および管理の仕組み自体も、各機関がミッションの基準として採用しているFISMAまたはFedRAMP ATO/P-ATOに基づく認可の対象となる可能性があることを、決して忘れないでください。
ステップ6：役割と責任を明確にする
概要：エンタープライズアプリケーション戦略の各要素について、責任の所在を明確にします。
エンタープライズアプリケーション戦略では、目標と優先事項を明確にするだけでなく、役割と責任についても定める必要があります。
把握しておくべき事項：
- アプリケーションポートフォリオの最適化とセキュリティ確保に関する意思決定権（例：テクノロジーの選定、アプリケーションの処遇、ユーザーアクセス管理）を持つのは誰ですか？
- 各アプリケーションへの特権ユーザーアクセス権を持つのは誰ですか？
- 各環境における各アプリケーションのデプロイ、運用、保守は誰が担当していますか？
- エンタープライズアプリケーションポリシーへの準拠は、誰が担当しますか？
- エンタープライズアプリケーション戦略の目標が遵守されているかを監視するのは誰ですか。また、その担当者は誰に指標を報告しますか？
- オープンソースやサードパーティのコンポーネント／サービスプロバイダーを含むベンダーが要件を遵守しているか、誰が監視しますか？
- すべてのアプリケーションとアプリケーションサービスを確実に把握するのは誰ですか（アプリケーションとサービスは継続的に変更され、追加または削除されます）？
これらの責任は、個人、複数部門で構成される委員会、さらには部門全体が担う場合があります。いずれの場合も、責任の所在を明確に定める必要があります。実際には、コンプライアンス体制で求められる以上に詳細な定義が必要になることもあります。
より先進的な組織では、アプリケーションの企画段階など、開発プロセスの早期にこうした責任の所在を定めるため、運用プロセスと自動化を導入します。重要な機能を支える数百、場合によっては数千ものアプリケーションが存在するマルチクラウド環境では、アプリケーション戦略とそれに対応するポリシーによって、責任の所在を明確にする必要があります。
エンタープライズアプリケーション戦略の適用
エンタープライズアプリケーション戦略を策定した後、その目的を果たすには、戦略を確実に実行する必要があります。そのための仕組みには、プロセスの自動化に組み込む「ハード」なガードレール（ユーザーアクセス制御、コードのチェックイン時に行う脆弱性スキャンなど）に加え、従業員研修や能力・意識の向上といった「ソフト」な施策も含める必要があります。
堅牢なアクセス制御を実装する
アクセス制御ポリシーは、エンタープライズアプリケーション戦略で定義された運用上の役割と責任を支えるとともに、オンプレミスとクラウドの両方にあるすべてのアプリケーションに適用する必要があります。特権ユーザーはアプリケーションに対する管理者権限またはroot権限を持つため、高度なAPTの標的になる可能性があるなど、アプリケーションにリスクをもたらします。そのため、特権ユーザーのアクセスには特に注意を払う必要があります。
特権ユーザーに推奨される特別な対策は次のとおりです。
- 特権ユーザーは、必ず別のグループに分ける必要があります。 アクセス制御ソリューション内で「高リスク」と定義し、すべてのユーザーやすべてのアプリケーション分類レベルには適用しない可能性があるセキュリティ制御を必須としてください。
- リモート認証では多要素認証を必須とする必要があります。 有効な認証情報を使用しているものの第2の認証要件を満たさないアクセス試行（認証情報が共有されていた環境での侵害により、攻撃者が有効な認証情報を入手した場合など）、または直近の有効なログインに基づいて物理的に移動不可能な場所からのアクセス試行（同じユーザーが米国で正常にログインした2時間後に東欧からログインを試みた場合など）があった場合は、追加のセキュリティレビューが完了するまでアカウントをロックする必要があります。
- 管理アクセスは、業務遂行のためにこのレベルのアクセスを日常的に必要とする、適切な訓練を受けた担当者にのみ許可する必要があります。 緊急時や特別なプロジェクトのために一時的なアクセス権を付与する場合は、別のユーザーグループを使用し、アクセス権の削除を忘れた際にシステム管理者へ通知する自動利用監視を設定する必要があります。利益相反を避けるため、アクセス権が適切かどうかを定期的に確認し、アプリケーションの担当チームやアプリケーションへのアクセス権を付与するチームから独立した立場で審査を完了する必要があります。特権ユーザーが長期間アカウントにアクセスしていない場合は、そのアクセス権が本当に必要かどうかを確認する必要があります。
- アプリケーションに対する特権ユーザーのすべてのアクセスについて、適切な監査記録をログに記録する必要があります。 これには、そのユーザーアカウントによる変更も含まれます。
クラウドのアクセス制御について、このレベルの可視性と自動化を実現することは、一般にこれらの機能が標準では提供されていないため、難しく、コストもかかる場合があります。ただし、サードパーティーのライセンスを利用すれば実現可能であり、その重要性を考えれば、十分に価値のある投資です。
従業員と関係者への継続的なトレーニング
アプリケーションが着実に増加し、攻撃者が標的とするアプリケーションやそのアクセス権を持つ人物を特定するために利用できる情報がメディアにあふれる今、セキュリティ意識向上トレーニングの重要性はかつてないほど高まっています。
スピアフィッシングは攻撃者の常套手段であるため、フィッシング対策トレーニングに重点を置く必要があります。2018年F5 Labsフィッシングおよび不正行為レポートによると、従業員に10回を超えるトレーニングを実施することで、フィッシングの成功率を33%から13%まで低減できることが明らかになりました。しかし、適切な教材を用いたセキュリティ意識向上トレーニングが十分な頻度で実施されることはほとんどありません。コンプライアンス要件を形式的に満たすための画一的な意識向上トレーニングサービスでは、従業員が情報セキュリティにおける自身の役割を理解できず、当事者意識を持てないおそれがあります。侵害リスクの低減が目的であれば、組織に合わせてカスタマイズしたトレーニングを頻繁に実施することが効果的です。
攻撃者に休みはありません。そのため、従業員は常に警戒を怠らないことが求められます。継続的に疑問を持ち、探究する文化は、あらゆる組織、特に連邦政府機関や、連邦政府に製品やサービスを提供する企業にとって標準であるべきです。従業員は、アプリケーションやデータにアクセスできることを理由に、自身が標的となり得ることを認識する必要があります。また、そのアクセス権やデータが敵対的な国家によってどのように利用されるか、あるいは営利目的のサイバー犯罪者によって売却され、その後、敵対者に購入される可能性があることも認識しておく必要があります。
まとめ
デジタルトランスフォーメーションを成功させるには、すべての組織がエンタープライズアプリケーション戦略とそれに対応するポリシーを策定し、従業員に教育を行う必要があります。レガシー、ハイブリッド、モダンの各種アプリケーションが数多く混在する連邦政府機関では、特に重要です。信頼性とセキュリティを確保し、認可されたデジタルサービスを提供するには、こうした取り組みが欠かせません。
アプリケーションは、あらゆる組織のデジタルトランスフォーメーションの中核です。ソフトウェアの開発・導入方法が急速に変化する中、アプリケーションは組織にとって最大の価値の源泉であると同時に、最大の脆弱性の要因でもあります。ここで説明するアプリケーション戦略とポリシーの構成要素は、あらゆる組織がデジタル化の目標を安全に実現するために不可欠な基盤となります。アプリケーションポートフォリオのリスクプロファイルは日々高まっているため、組織は戦略とポリシーの正式な策定を早急に進める必要があります。
1 米国行政管理予算局のCloud Smart戦略
2 F5 Labs：10年間のデータ侵害から得た教訓
3 犯罪者が水槽をハッキングし、カジノからデータを窃取, Forbes
4 Targetの侵害は基本的なネットワークセグメンテーションの不備が原因, ComputerWorld
5 2018年版ソフトウェアサプライチェーンの現状, Sonatype
公開日：2021年1月11日