Secure Access Service Edge（SASE）は、オンプレミス、クラウド、エッジシステムが交わる領域で生じるセキュリティ上の課題の多くに対応できることを実証してきました。多くの組織はデジタル運用を維持するためにこれらのシステムを組み合わせる必要がありますが、SASEの導入には独自の課題が伴います。しかも、それは一度で完了するプロセスではありません。
効果的なSASEフレームワークを構築するには、組織はセキュリティガバナンスを見直し、ポリシーの重点を切り替え、社内チームを再教育し、社外との新たな関係を築く必要があります。この移行には6~18カ月、場合によってはそれ以上かかることもあり、レガシーシステムとSASEシステムの両方を同時に維持しながらセキュリティを確保する必要があります。
第1段階: 包括的なインフラ評価
この監査フェーズでは、シャドーインフラが発見されるのが一般的です。誰も導入した覚えのない古いアプライアンス、機能が重複する冗長なセキュリティツール、より広範なプラットフォームを購入した後も完全には廃止されないままのポイントソリューションなどが典型例です。単なる棚卸しにとどまらず、組織はネットワークトポロジー、トラフィックの流れ、アプリケーション間の依存関係、そして現在のセキュリティポリシーの根拠となるコンプライアンス要件を文書化する必要があります。
Omdiaのプリンシパルアナリスト、John Grady氏は、こうした自己評価を行うことで、SASEのどの側面が組織にとって最も重要か、そしてその目的を達成するために既に何が整っているかを把握できると述べています。
「2年後、3年後にどこにいたいかを自問してください」とGrady氏は言います。「その評価を基にロードマップを構築するのです」
第2段階: 制御された環境でのパイロット展開
まずは特定のセグメントを対象としたパイロットから始めることで、問題が発生した場合の影響を最小限に抑えられます。理想的なパイロット対象としては、リモートワーカー群(従来のVPNの限界が最も顕著に現れる領域)、レガシーインフラからまだ移行していない新規拠点、あるいはセキュリティ上のギャップがあってもコアビジネスの運用を脅かさない非重要なSaaSアプリケーションなどが挙げられます。
パイロット展開は、季節変動、統合時のエッジケース、さまざまな負荷条件下でのパフォーマンスパターンを把握するために、一般的に3~6カ月という長期間にわたって実施すべきです。パフォーマンスのベースラインを確立し、SASEポリシーが必要なトラフィックを正しく許可しつつ不要な通信をブロックしていることを検証したうえで、そのSASEプラットフォーム特有のインシデント対応、ポリシー変更、トラブルシューティングに関する運用手順を整備します。
「最も痛みが大きい領域から着手してください」とGrady氏は言います。例えば、最大の課題がリモートアクセスであればゼロトラストネットワークアクセスから、拠点間接続であればSoftware-Defined Wide Area Network(SD-WAN)から、Software-as-a-Service(SaaS)の管理であればCloud Access Security Broker(CASB)から始めるべきだということです。
第3段階: ワークロードグループの段階的移行
セキュリティインフラ全体を一気に切り替えようとするのではなく、ワークロードグループを順番に移行していくべきです。次の段階に進む前に、各移行を検証する時間を確保してください。典型的なフェーズとしては、リモートワーカーとモバイルデバイス、支社ネットワークとSD-WAN接続、集中管理されたクラウドアプリケーションへのアクセス、そして機密性の高いオンプレミスワークロードが挙げられます。
リモートワークから先に移行することで、組織はSASEプラットフォームの運用経験を積みながら、最も痛みの大きいレガシーVPNの問題に対処でき、より複雑なシナリオに取り組む前に社内の専門知識と組織としての自信を築くことができます。次に自然な流れとして支社オフィスの移行が続き、分散拠点にもSASEの恩恵を拡大するとともに、Multiprotocol Label Switching(MPLS)からSD-WANに至るネットワーク機能をSASEに統合することで、しばしば即座にコスト削減効果が得られ、それが残りの移行作業の資金源にもなります。
各移行フェーズでは、予期しない問題が発生した際に迅速にロールバックできるよう、1~3カ月はレガシーインフラとの共存状態を維持すべきです。
第4段階: ポリシーの再設計とガバナンスの進化
SASEの導入は、レガシールールを機械的に置き換えるのではなく、包括的なポリシーの再設計を引き起こすべきものです。組織は移行期間中に「ポリシーの整理整頓」を実施し、シャドールールの削除、過度に緩いポリシーの排除、重複するルールの統合、そして将来のポリシー保守を可能にする一貫した命名規則の適用を行うべきです。
最新のSASEガバナンスは最小権限の原則を取り入れるべきです。これは、所在地に基づく広範なネットワークアクセスを与えるのではなく、ユーザーとアプリケーションに特定の業務に必要な権限のみを付与するという考え方です。アイデンティティ主導のポリシー、すなわちアクセス権がネットワークのIPアドレスではなく、ユーザーのアイデンティティ、デバイスのセキュリティ状態、アプリケーションの機密性に基づいて決まる仕組みへの転換には、ネットワークベースのセキュリティを前提に発展してきたロール構造やアクセス管理の慣行を見直すことが求められます。
この再設計プロセスは、セキュリティチームとビジネスオーナーの協働で進めるのが最善です。セキュリティチームはポリシーの意図を理解し、ビジネスオーナーは実際のアクセス要件を理解することで、SASEポリシーがセキュリティ原則と運用上の実態の両方を反映できるようになります。
「ポリシー変更に順序をつけたロードマップを作成し、ゼロトラストの原則への長期的な整合性を保ちながら、まずは手早く成果が出るものから着手してください」と、Voodoo Securityの創業者兼CEOであるDave Shackleford氏は助言しています。
第5段階: トレーニングと組織の進化によるスキルギャップの解消
SASEの導入には、従来のネットワークやファイアウォール管理とは大きく異なるITスキルが求められます。MPLS回線やファイアウォールのルールベースの管理に慣れたネットワーク管理者は、クラウドネイティブなアーキテクチャ、API主導の自動化、アイデンティティ統合、ゼロトラストの原則を理解する必要があります。脅威の検知と対応に注力してきたセキュリティチームには、クラウド提供型のセキュリティ、分散したPoP(Point of Presence)全体にわたるポリシーのオーケストレーション、そしてローカルでの可視性を欠くクラウドプラットフォーム上でのセキュリティ実施状況のデバッグに関する専門知識が必要になります。多くのチームは、まず導入したプラットフォームの公式アカデミーや認定トラックから着手します。そこには通常、アーキテクチャの概要、ハンズオンラボ、製品固有の展開パターンがひとまとめになっています。MSSPやMSPを通じてサービスとして導入する場合は、多くの場合そのサービスプロバイダーがトレーニングを提供します。
第6段階: 継続的な最適化とガバナンスの進化
SASEの導入は初期展開をもって完了するものではありません。むしろそこから、組織がポリシーを継続的に洗練させ、セキュリティ実施状況がビジネス要件と整合しているかを検証し、変化する脅威の状況に適応していく、継続的な最適化サイクルが始まります。
組織は四半期ごとのポリシーレビューを設け、現行のSASEポリシーが依然としてビジネス要件を反映しているか、ポリシー変更によって意図しないギャップが生じていないか、脅威インテリジェンスがポリシー調整の必要性を示していないかを評価すべきです。パフォーマンスモニタリングでは、ユーザー数やトラフィック量が増加してもレイテンシ、スループット、信頼性が許容範囲内に収まるよう、アプリケーション固有の指標を追跡すべきです。
最も成功しているSASE導入事例は、このプラットフォームを完了日のある一度限りのプロジェクトとしてではなく、継続的な注意を必要とする生きたインフラとして扱っています。SASE移行の途上にある企業は、包括的なグローバル展開の実現には1~2年、多額の投資、そしてITリーダーシップの関与を要する組織の根本的な変革が必要であることも認識しておくべきです。
SASEガバナンス体制を確立し、継続的な最適化を担う推進役を任命し、継続的な改善をIT運用に組み込むというこの考え方を取り入れた組織は、SASEへの投資からはるかに大きな価値を実現しています。
レガシーなアプライアンス型セキュリティから統合型SASEへの移行が難しいのは、まさにこの変革が技術面にとどまらず、より深いところにまで及ぶからです。それは、クラウドネイティブなアーキテクチャにおいてセキュリティをどう統治するかという発想そのものの見直しを求めます。しかしその見返りとして約束される成果は大きく、業務の簡素化、セキュリティの向上、そして分散型の労働力への対応が実現します。
翻訳元: https://www.darkreading.com/cloud-security/how-to-build-sase-framework
