29
ゼロトラスト・ アーキテクチャ に向けた詳細な 計画 実用的な実装ガイド - Akamai Chief Technology Officer Charlie Gero 概要 ホワイトペーパー

A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

  • Upload
    others

  • View
    1

  • Download
    0

Embed Size (px)

Citation preview

Page 1: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 1

ゼロトラスト・アーキテクチャに向けた詳細な計画

実用的な実装ガイド - Akamai Chief Technology Officer Charlie Gero

概要

ホワ

イト

ペー

パー

Page 2: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 2

目次

ネットワークアーキテクト、セキュリティエンジニア、CTO、CISO、IT およびセキュリティに関するその他の意思決定者に役立つガイドです。

ゼロトラスト・フレームワークのスコーピング、設定、導入、実装、管理の担当者には、このガイドが示す段階的な導入、展開手法が参考になります。

組織のリーダーは、ゼロトラストの社内での位置付けを適切に定め、ゼロトラスト・アーキテクチャを効率的に実現するためのガイダンスや論点を知ることができます。

このガイドの対象読者

ネットワークアーキテクチャの大まかな歴史 3

クラウドの普及 4

ゼロトラスト・セキュリティ・アーキテクチャ 5

Akamai のエッジ・セキュリティ・サービス 6

アプリケーションアクセスとネットワーク アクセス 8

ゼロトラスト計画 12

望ましい最終状態 13

アプリケーションアクセス 13

脅威防御 14

アーキテクチャの視覚化 14

完全移行への道のり 15

ステージングの前提条件 16

ユーザーの分類 17

ユーザーの分類方法 18

アプリケーション展開段階 18

1. アプリケーション事前確認段階 19

2. アクセスプロキシ準備段階 20

3. テストラボ登録段階 21

4. セキュリティ強化段階 22

5. パフォーマンス強化段階 24

6. 外部ユーザー登録段階 25

7. 内部ユーザー登録段階 26

8. VLAN 移行段階 27

ステージング後の作業 28

まとめと次のステップ 28

Page 3: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 3

過去数年の間に良いことも悪いことも、さまざまな変化がありました。しかし変わらなかったことが 1 つあります。それは、ほとんどの企業が基本的なハブ・アンド・スポーク型のアーキテクチャを利用しているという点です。

このアーキテクチャは、以前は理にかなったものでした。はるか昔、ビジネスやコアインフラがインターネット上にあふれる前、企業はワークロードを自社のデータセンターで処理していました。これらのデータセンターには、重要なインフラやアプリケーションが配置されています。支店、小売店の店舗、およびサテライトがオンライン化されるに伴い、中央のアプリケーションへのアクセスも必要となりました。企業は、すべてのネットワーキングをコアデータセンターにバックホールすることで、こうしたニーズを反映したネットワークを構築しました。そして最終的に、データセンターはすべての処理が発生する中心的な場所となったのです。

時が進むにつれて、商業的に実現可能な革新技術としてインターネットが台頭し始めました。それまで複雑なプライベート・グローバル・ネットワークを構築するという方法を採ってきた企業や通信事業者は、必然的に自分たちが最もよく知っているやり方で、こうしたプライベートな要求に対応しました。社内アプリケーションがホストされているデータセンターに、企

業サービスと消費者サービスを導入し、それらへのルートを提供するインターネットリンクを購入したのです。そうすることで、意図せずに 2 つの目的が果たされました。つまり、外部の顧客がネットワークに入れるようになっただけでなく、無数の支社に散らばる社内従業員がネットワーク外に出て行けるようになったのです。ハブ・アンド・スポーク型はしばらくの間、ネットワークアーキテクチャの圧倒的主流であり続けました。

そのうちに攻撃者たちがこのアーキテクチャを利用し始め、結果としてまったく新しい業界が生まれました。データセンターのセキュリティスタックです。ハブ・アンド・スポーク型アーキテクチャでは、データセンターでインターネットトラフィックが集約されるため、大容量の回線を保護するために大規模かつ強力な仕組みが開発されるようになりました。こうして、インバウンドトラフィックはファイアウォール、侵入検知、侵入防御によって制御され、アウトバウンド方向は、セキュア Web ゲートウェイによって利用規定が強化されました。

トラフィックが集約される場所に、このようなセキュリティシステムが導入され、これが普及していくことで、ハブ・アンド・スポーク型のネットワークアーキテクチャはさらに優勢となっていきました。しばらくの間、セキュリティに対する「堀と城」のアプローチは存続可能に思われ、外部の者はすべて悪であり、内部の者はすべて善であるというネットワーク境界の考えが支配的なままでした。

しかし、クラウドによってこの状況は根底から変化しました。ユーザーとアプリケーションがどこに所在していても、それがたとえ境界の外であっても、対応できるセキュリティ対策が必要となったのです。

ネットワークアーキテクチャの大まかな歴史

Page 4: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 4

図 1:従来の境界セキュリティでは、1 人の攻撃者が境界の弱点の 1 つを悪用して内部に侵入できれば、その後、横方向に移動してリソースにアクセスできる

E メール ゲートウェイ

アプリケーション

セキュア Web ゲートウェイ

ファイアウォール

仮想プライ ベート

ネットワーク

データの 損失と防止

侵入検知 システム

侵入防止 システム

ユーザー

データベース

サーバー

デバイス

従来の境界 セキュリティ

簡単に言えば、アプリケーションは移動しています。しかし、移動しているのはアプリケーションだけではありません。今は、従業員や職場も変わりました。人々が仕事をするタイミング、方法、場所は、いずれもオフィスの四方の壁の外へと広がりました。

その結果、ネットワーク境界は、少なくとも、認識できる形では消失しています。ユーザーとアプリケーションは、堀の内側と同じように堀の外側にも存在しているはずです。そのため、巧妙な持続的脅威を受けると、意図せずに攻撃者を境界内に侵入させ、最も貴重な資産への全面的なアクセスを許可してしまう可能性が高くなります。

20 年前は有効だったセキュリティやアクセス方法を今の時代に利用することは、よく言っても不適切ですし、悪く言えば非常に危険です。Forrester Research

は次のように述べています。クラウドの普及

「データエコノミーによって、今日のネットワーク、つまり境界ベースのセキュリティは役に立たないものとなっています。企業が複雑なビジネスエコシステム全体で情報や知見を収益化している今、社内と社外の境界という考え方は時代遅れであり、危険ですらあります。」

— Forrester, Future-Proof Your Digital Business With Zero Trust Security

Page 5: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 5

従来のセキュリティ アーキテクチャ

現実

図 2:もはや信頼できる内部も信頼できない外部も存在しない

ユーザー

アプリケーションデバイス

ブランチ オフィス

これは単なる見解ではありません。その証拠に、過去

5 年間に確認された大規模なデータ漏えいのほとんどは、ネットワーク境界内の信頼が悪用された結果として生じたものでした。

こうした問題をさらに深刻化させる要因として挙げられるのは、ネットワーク境界内で使用するように設計されたアプリケーションは多くの場合、セキュリティプロファイルが一番低く設定されているという点です。とはいえ、もしもあなたが 10 年前の開発者で、システムにアクセスできるのは許可された正当な従業員だけであると想定していたなら、どうしたでしょうか。膨大な数のハッカーが自分のインターネットベースアプリケーションを攻撃すると知っている現在の開発者と同等の防御策を講じたでしょうか。

では、どうすればよいのでしょう。

「ゼロトラスト」は、この分野のソートリーダーであり、当時 Forrester のアナリストであった John

Kindervag 氏が提唱し、名付けたソリューションです。その背後にある本質は非常にシンプルですが、非常に強力です。それは、信頼とは場所に帰属するものではないということです。ファイアウォールの内側にあるというだけで、そこにあるものを信用すべきではありません。セキュリティに関しては、どのようなマシン、ユーザー、サーバーも信頼できることが証明されるまで信頼しないという悲観的な立場をとります。

証明には強力な認証と認可を使用し、信頼が確立されるまでデータはいっさい転送されません。さらに、分析、フィルタリング、ロギングを使用して、ふるまいの正当性を検証し、セキュリティ侵害の兆候を継続的に監視します。

このように考え方を根本的に変えれば、過去 10 年 間に発生した膨大な数のセキュリティ侵害に打ち勝つことができます。攻撃者が時間をかけて境界の弱点を悪用しようとしても、堀の内側に侵入して機微な情報やアプリケーションを使用することはできません。もう堀などないのです。あるのはアプリケーションとユーザーのみであり、アクセスするには、それぞれが事前に相互認証し、認可を確認する必要があります。

ゼ ロ ト ラ ス ト・ セ キ ュ リティ・アーキテクチャ

データ本社

Page 6: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 6

ネットワークは常 に敵対的なものとみなす

ネットワークには、外部にも内部にも常に脅威が存在して いる

ネットワーク上の 位置だけでネットワーク内の信頼を 判断することはできない

すべてのデバイス、ユーザー、ネットワークフローに認証と認可を適用する

ポリシーは動的なものであり、その作成にはできるだけ多くのデータソースを 用いる必要がある

では、どのようにこれを実現するのでしょうか。

ゼロトラスト・アーキテクチャには、さまざまな提供方法があります。一般的な戦略として、すべてを独自

DMZ 内で実行するアクセス・プロキシ・アーキテクチャが考えられます。しかし、この方法では、攻撃の吸収、無限のキャッシュ帯域幅の提供、必要に応じたリソースの自動スケーリングといったクラウドの機能が制限されます。

SaaS

Enterprise Application Access Client

Enterprise Application Access Connector

クライアントレス

IaaS

オンプレミス

Salesforce Microsoft 365

AWS、Azure、Google Cloud Platform

Akamai Intelligent Edge Platform

クライアントを使用

Akamai IdP

MFA / SSO

ポスチャー/リスク *

ポリシーエンジン

ポリシーアクセス

サードパーティ IdP

Web

Exchange

SSH

RDP

* クライアントが必要

Akamai のエッジ・セキュリティ・サービス

図 3:Akamai のクラウドベースの ZTNA ソリューションは、継続的かつ動的にアクセスの判断を実行

ゼロトラストの原則

Akamai はクラウドネイティブな企業であり、創業以来 20 年以上にわたりエッジで事業を展開してきました。Akamai が設計したゼロトラスト・ネットワーク・アクセス(ZTNA)テクノロジーは、アイデンティティ認識型プロキシですが、クラウドに置かれ、オンデマンドで拡張可能です。また、CPU 負荷の高い処理はお客様の機器ではなく当社のプラットフォーム上のリソースで実行し、攻撃を吸収します。さらに、アプリケーションの種類に応じ、クライアント方式およびクライアントレス方式でユーザーに最も近いキャッシュコンテンツを配信できます。Akamai はこのソリューションを Enterprise Application Access、略して EAA

と呼んでいます。仕組みは以下に示すとおりです。

Page 7: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 7

され、その後、デバイスアイデンティティ機能が実行されます。また、できる限りユーザーに近い Akamai

POP(Point of Presence) で、Web Application

Firewall(WAF)、ボット検知、ふるまい分析、キャッシングなど、その他のサービスを追加することもできます。そうすることで、クラス最高レベルのパフォーマンスを実現し、潜在的な攻撃者を物理的な場所、アプリケーション、データからできる限り遠ざけることができます。

ユーザーとマシンが認可されると、クライアントからの接続が Enterprise Application Access Connector

からのアウトバウンド接続と結合されます。ユーザーセッションのトラフィックは、結合されたアイデンティティ認識型プロキシ接続を介して Enterprise

Application Access Connector に送信され、要求されたアプリケーションまたはサービスに接続されます。その時点で、完全なデータパスが確立され、その後のアクセスはすべて、アイデンティティ、デバイス、およびユーザーコンテキストに基づいて継続的かつ動的に判断されます。

すべてのアセット間のネットワークフローを制御

アイデンティティおよびクラウドへのアクセス権を付与

認証と認可

アプリケーションアクセスとネットワークアクセス

すべてのアプリケーシ ョ ン(IaaS、SaaS、オンプレミス)に対する最小権限のユーザーアクセス

VPN の廃止

サービスの挿入

エッジでの セキュリティ

アプリケーションパフォーマンスの向上

高度な脅威に対するセキュリティ対策の強化

このアーキテクチャでは、組織のネットワーク全体ではなく、アプリケーションごとにアクセス権を提供できます。ただし、DMZ にアクセスプロキシを配置するのではなく、ファイアウォールの内側で Akamai

Enterprise Application Access Connector と呼ばれる小さな仮想マシン(VM)を実行します。この VM は

DMZ 内にある必要はなく、むしろあってはなりません。アドレスがプライベート IP 空間上にあるようにし、インターネットから直接到達できないようにする必要があります。つまり、ファイアウォール内に配置する他のアプリケーションとまったく同じように扱う必要があります。

Enterprise Application Access Connector は起動するとすぐに、Akamai プラットフォームとの暗号化接続を確立します。Akamai クラウドに接続すると、Akamai のサーバーから設定をダウンロードし、接続に対応できる状態になります。

社内アプリケーションのユーザーがサービスにアクセスしようとすると、DNS CNAME によって Akamai

に転送され、Akamai Intelligent Edge Platform に接続されます。エンドユーザーとそのデバイスがすべてのチェックに合格すると、認証、多要素認証(MFA)、およびシングルサインオン(SSO)へとルーティング

機能:ゼロトラスト・ネットワーク・アクセス

Page 8: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 8

このアクセス方法を VPN の一種と考える読者もいるかもしれません。しかし、この誤解が理解を一層困難なものにします。VPN はネットワークレベルのアクセスを提供します。Akamai Enterprise Application

Access を使用すると、ユーザーはネットワークにアクセスしなくても、アプリケーションへのアクセス権を取得できるようになります。

シンプルな VPN 設定を選択する場合は、多くの企業で行われているように、ログインユーザーに対してネットワーク全体への IP レベルのアクセスを許可することになるでしょう。これは非常に危険です。コールセンターの従業員がソース・コード・リポジトリに

IP アクセスする必要があるでしょうか。あるいは、自社の課金システムを使用している業務委託先が、クレジットカード処理端末にアクセスする必要などあるでしょうか。役割を果たすために必要なもののみへのアクセス権を付与すべきです。

この問題の解決法として、ファイアウォールの内側で複数の VLAN を使用してアプリケーションをセグメントに分け、VPN アグリゲーターで個々のユーザーまたはグループに時代遅れの IP 範囲ベースのルールを

適用する方法も考えられます。しかし、この方法は脆弱で、ミスも生じやすくなります。おそらく、誰かがメンテナンスを行っていて、マシンを新しいラックに移動したのかもしれません。あるいは、IP を新しい範囲に割り当て直す必要があったのかもしれません。ユーザーは前触れなくロックアウトされ、そのためサポートへの電話が殺到することになります。または、ソフトウェアのアップグレード時にアプリケーションのアーキテクチャが変更され、ユーザーはそのワークフローの一部として別のマシンにリダイレクトされるものの、ファイアウォールのルールが更新されていないために、特定のユーザーまたはグループがそのマシンにアクセスできないことがあります。このアーキテクチャは非常に複雑であり、ダウンタイムをゼロにするためには、アプリケーションオーナー、ネットワーク管理者、セキュリティグループの間で綿密に調整を行う必要があります。

このアクセス方法には、明確で重要な利点があります。それは、パフォーマンスとセキュリティが最も重視されるアクティビティを、世界各地の 4,100 か所以上に分散している Akamai POP のうち、エンドユーザーに最も近いエッジで実行できるという点です。さらに、アプリケーションへの機微な進入経路はアプリケーションのリバーストンネルを介するため、境界の IP

は見えなくなり、ボリューム型攻撃のリスクが軽減されます。

従業員のサイバー判断能力に自信または確信が持てない CISO の割合

Gartner、Securing the Fully Remote Workforce

88%

アプリケーションアクセスとネットワークアクセス

Page 9: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 9

過去の事例から、そのような調整が失敗したときに多くの場合何が起こるのか、Akamai ははっきりと把握しています。管理者たちはベストプラクティスに従いたいと思っています。しかし、どうしようもない局面では、恐ろしいことに IP ANY / ANY ALLOW ルールをその場しのぎで追加することになり、影響を受けるユーザーは、表面下の問題が診断されて修復されるまで、すべてにアクセスできるようになるのです。しかし、過去の欠陥を修復して修正する時間を取れない場合が多々あります。やはり、自由な水平アクセスにおけるセキュリティ上の欠点を克服するには、VPN

の使用に際してかなりの複雑さと運用上のオーバーヘッドを受け入れる必要があり、その複雑さゆえに欠陥の発生やその場しのぎの対応が行われることになり、時間の経過とともにセキュリティの状態が悪化していくのです。

パフォーマンスに関しても、同じトレードオフが生じます。最もシンプルな VPN では、すべてのトラフィックがデータセンターのインフラに戻ります。その結果、ヘアピン効果によってインターネットプロパティや SaaS へのアクセス速度が極端に低下したり、Facebook や YouTube といった業務外のトラフィックのためにデータセンター内のインターネットアップリンクで輻輳が増大する可能性があります。なぜ、すでにオフプレミスになっているユーザーのために、通常のインターネットアクセスをバックホールするのでしょうか。

「エンタープライズのデータセンターを接続要件の中心に置くネットワーク・セキュリティ・アーキテクチャが、デジタルビジネスに必要な動的アクセスの阻害要因になっています。」

— Gartner、The Future of Network Security Is in the Cloud

392 万ドル企業が被るデータ漏えいの平均コスト

25,575 漏えいにおける平均レコード数

150 ドル(世界)/ 242 ドル (米国)

各レコードの平均コスト

出典:IBM Security/Ponemon Institute、2019 Cost of a Data Breach Study

データ漏えいの結果

Page 10: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 10

このようなパフォーマンスへの負担を克服するために、管理者は多くの場合、スプリットトンネルを使用し、VPN を通過させる IP 範囲とインターネットに直接データ転送する IP 範囲を指定します。この方法は、内部境界が 1 つだけの場合は非常に効果的で簡単です。しかし、IaaS プロバイダーに複数のデータセンターや仮想プライベートクラウド(VPC)を追加すると、格段に複雑になってきます。管理者は、すべてのデータセンターに VPN アグリゲーターを導入するかどうかや、マルチポイント分割トンネルを効率的に管理する方法を決定する必要があります。

繰り返しになりますが、これらの解決法は理論的にはすべて可能です。お客様によっては、既にそれらをいくつか組み合わせて使用しているかもしれません。それらをうまくやり遂げ、維持し、それらの実装が存続する間ずっと適切なセキュリティとパフォーマンスを提供しなければなりません。問題は、そのために必要なタスクの運用が複雑すぎるため、継続的に正しく動作させるのが困難なことです。多くの場合、企業は、従業員がアプリケーションにアクセスできているため、すべてが最適に機能しているはずだと自らを納得させています。その場しのぎの対応の結果、油断に付け込まれて、甚大なセキュリティ侵害やパフォーマンスの低下が発生し、業務が停止したり従業員の生産性が大幅に低下することになります。

akamai.com | 10

Page 11: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 11

VPN に価値がないと言っているわけではありません。むしろその逆です。複数のデータセンターインフラがある場合のサイト間アクセスは、VPN がメリットをもたらすケースの 1 つといえます。単に、アプリケーションへのユーザーのアクセスについて議論するためのパラダイムとして、ネットワークレベルのアクセスは適していないというだけです。なぜなら、ネットワークレベルのアクセスでは、簡便性に対するセキュリティとパフォーマンスの折り合いのバランスが良くならないからです。

Akamai Enterprise Application Access のようなプロキシベースのアプローチには、アプリケーションレベルのアクセス権を提供できるという強みがあります。アプリケーションレベルのアクセス方式を使用すれば、パフォーマンスとセキュリティは複雑さの問題と切り離されます。説明が簡単であることからも、このことは明らかです。

相互にローカルなアプリケーション(たとえば、同じデータセンターまたは同じ VPC にホストされているものなど)すべてを、1 つのプライベートネットワーク IP 空間または restricted VLAN に割り当て、そのマイクロ境界内にアクセスプロキシを配置すれば、完了します。

アプリケーションオーナーはアクセスプロキシに独自のセキュリティポリシー(誰がどのような目的でアクセスできるか)を設定できます。そしてさらに有利なのは、ユーザーがどこにいてもかまわないという点です。オンプレミスとオフプレミスの区別はありません。なぜなら、エンドユーザーを含めて、ネットワーク境界というものが存在しないからです。オフィスの外や喫茶店で仕事をしている従業員もオフィス内の従業員も同じです。重要なのは、そのユーザーが認証されているかどうか、そしてマシンが安全であるかどうかだけです。

アプリケーションレベルのアクセス方式を使用すると、展開や使用が容易なうえに、クラス最高レベルのパフォーマンスを実現できます。アプリケーションがどこにホストされていても、またユーザーがどこにいても、ユーザーはインターネットを使用して直接アプリケーションにアクセスできます。アグリゲーターや経路内にない中間物を介することなく、インターネットで宛先までパケットをルーティングできるのです。

実際、アプリケーションレベルのアクセス方式では、内部ネットワークがシンプルなゲスト Wi-Fi と一体化していることも少なくありません。前述のとおり、ゼロトラストが真価を発揮できるようにするためには、内部ユーザーと外部ユーザーを同等に扱う必要があります。デフォルトで、すべてのユーザーが信頼できないのです。

アプリケーションレベルのアクセス方式を使用すれば、パフォーマンスとセキュリティは複雑さの問題と切り離されます。オフィスの外や喫茶店で仕事をしている従業員もオフィス内の従業員もみな同じです。重要なのは、そのユーザーが認証されているかどうか、そしてマシンが安全であるかどうかだけです。

Page 12: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 12

どのような課題に直面しているか?

主な成功要因は何か?

解決したいことは何か?

検討事項:

ユーザーを保護する ユーザーのマルウェア 感染を防ぐ

資産を保護する すべてのトランザクションに認証/認可を 適用する

ユーザーを知る 誰も信頼しない

ゼロトラスト計画

重要な目標の再確認

Page 13: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 13

アプリケーションアクセス

最新のゼロトラストでは、すべてのアプリケーションを場所と目的に基づいて独立したマイクロ境界に分割します。これらのマイクロ境界は、プライベート IP 空間を持つプライベート VLAN 上に配置すべきであり、その手前にあるアクセスプロキシを除いて直接アクセスできないようにします。

Akamai では、アプリケーションが侵害された場合に水平方向の影響拡大や移動を阻止する目的でマイクロ境界内をさらに細かくセグメント化するかどうかについては、各社の判断に任せています。このような取り組みの理論的な価値は認めますが、実際のところ、そのようなセグメント化を適切に行うのは非常に複雑であり、セキュリティを強化するのに妥当とは言えません。境界の内側にある複雑なアプリケーションのタッチポイントを解消しようとしたことがある方なら、アプリケーション同士をセグメント化するといかに不安定になりやすいかご存知と思います。ただし、お客様の環境において、これが簡単かつ維持可能な方法で実現できるのであれば、採用することをお勧めします。

オンプレミスかオフプレミスかを問わず、どのようなアプリケーションにアクセスするにも、すべてのユーザーが Akamai Enterprise Application Access などのアイデンティティ認識型アクセスプロキシを経由する必要があります。そして、このようなアクセスプロキシでは、標準認証だけでなく MFA も実行する必要があります。また、特定のアプリケーションへのアクセス権を得るためのデバイス基準を取得する堅牢なデバイスポスチャー機能も必要です。

Akamai はさらに、ゼロトラストは認証と認可で終わるものではないと考えています。最近のスタックでは、アクセスプロキシを通過するトラフィックに関して、ある程度の検査と分析が必要となります。これは、 巧妙な持続的脅威や、意図的な悪意を持ったエンドユーザーからの防御に役立ちます。

WAF はアクセスプロキシの上層に不可欠なセキュリティシステムの 1 つであり、エンドユーザーから内部アプリケーションに向けて(意図的に、または意図せずに)アプリケーションレベルの攻撃が開始されないようにしています。他にも、人間/ボットの検知などの先進的なシステムを非 API サイトで活用し、適正なエンドポイントの背後でマルウェアによるなりすましが発生しないようにすることができます。

アプリケーションをオンラインにして、アクセスプロキシ経由でアクセスできるようにすると、DDoS 防御の重要性が増します。マイクロ境界とアクセスプロキシに対する攻撃を吸収できるプロバイダーと協力すれば、負荷が集中しても運用を継続できるようになり ます。

エンドポイントはもはや「組織のもの」ではありません。社内ネットワークに接続してデータにアクセスするエンドポイントは、かつて IT 部門が制御していましたが、BYOD や増加するモバイルワーカーにより、今では制御できなくなっています。 — Forrester、A Practical Guide to a Zero Trust Implementation

望ましい最終状態

Page 14: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 14

最後にもう 1 つ重要なことがあります。アプリケーションがクラス最高レベルのパフォーマンスを発揮できるようにするとともに、アクセス方式の変化をユーザーに受け入れてもらうだけでなく、支持してもらうためには、アクセスプロキシが接続されているネットワーク自体がパフォーマンスの面でメリットを提供できなければなりません。具体的には、CDN とインターネット・ルーティング・オーバーレイを活用すべきです。これらを組み入れることで、アクセスを可能にするだけでなく、従来方式よりもパフォーマンスを強化できます。

脅威防御

Akamai Enterprise Application Access のようなソリューションは、お客様のアプリケーションを攻撃者から保護します。しかし、デバイスがマルウェアに感染したり、フィッシングのリンクやランディングページを通じて認証情報が盗まれたりすることで、ユーザーが意図せずに攻撃者になってしまうこともあります。これを防ぐにはどうすればよいのでしょうか。ここで重要になるのが Web トラフィックに対する防御と検知です。

1 つのアプローチとして、Akamai Enterprise Threat Protector など、クラウドベースのセキュア Web ゲートウェイソリューションの導入が考えられます。これにより、ユーザーのすべての Web リクエストを検査し、リアルタイムの脅威インテリジェンスと高度なマルウェア分析テクニックを適用して、安全なコンテンツのみが配信されるようにすることができます。悪性のリクエストやコンテンツは事前にブロックされます。また、ラップトップに軽量エージェントをインストールすれば、ユーザーがどこから接続しても、一貫した保護を提供できます。

アーキテクチャの視覚化

すべてをまとめると、ゼロトラストが完全に実現された世界では、ユーザーとアプリケーションは次の図のようになります。

1 | プレゼンテーションのタイトルをここに入力 | © 2018 Akamai | 機密事項

概要ゼロ・トラスト・セキュリティリファレンスアーキテクチャ

脅威保護

コーポレートアプリ

データセンター

IaaSプロバイダー X

SaaSプロバイダー Y攻撃者

キープロダクト脅威防御 ► Enterprise Threat ProtectorDDoS/WAF ► Kona Site Defender または Web Application Protectorアイデンティティ確認とアプリへのアクセス ► Enterprise Application Access

Web

概要

アイデンティティ

4

アプリアクセス

5

6

DDoS/WAF

3

ブラウザー

クライアント

攻撃者

1

EDGE プラットフォーム

2

管理

図 4:ゼロトラスト・アーキテクチャでは、認証され認可されたユーザーとデバイスのみがアプリケーションやデータにアクセスできま図 4:ゼロトラスト・アーキテクチャでは、認証され認可されたユーザーとデバイスのみがアプリケーションやデータにアクセスできます。さらに、アプリケーションやユーザーをインターネット上の高度な脅威から保護します。す。さらに、アプリケーションやユーザーをインターネット上の高度な脅威から保護します。

Page 15: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 15

Akamai は、ゼロトラストに完全に対応したエンタープライズの在り方を含め、ゼロトラストについて包括的に検討してきました。ただし、最高のセキュリティが実現するのはセキュリティがシンプルである場合です。同じように、新しいアーキテクチャの導入も、シンプルかつフェーズ移行可能である必要があります。規模を問わず、どのような企業であろうと、インフラ全体を一晩で変えることはできません。ゼロトラスト自体が戦略であるように、その展開にも戦略が必要となります。

完全なゼロトラスト・アーキテクチャを達成する最善の方法は、まず、アプリケーションを管理可能な小さい単位でゼロトラスト・アクセス・モデルに移行していくことだと考えられます。1 単位のサイズはお客様が確保できるリソースの数によって異なります。企業によっては一度に 1 単位ずつしか移行できない場合もあります。いずれにせよ、移行される各アプリケーションは、ゼロトラストの完了までにいくつかの段階を経ることになります。各段階で、アプリケーションが正しく機能し、認可が期待どおりに実施されていることを確認します。

Enterprise Application Access は、クライアントのインストールを必要とすることなく、HTTP(S)、VNC、RDP、SSH のアプリケーションをサポートします。また、クライアントを使用することにより、デバイスポスチャー評価やその他のプロトコルにも対応できます。アクセスの決定を、デバイスのセキュリティ侵害の有無やエンドポイントのセキュリティポリシー順守状態といったサードパーティの脅威信号インテリジェンスに基づいて行うことも可能です。

実現するために必要なこと:ゼロトラストによって最終的に顧客の信頼を獲得できることを明確にします。ゼロトラスト・アーキテクチャは、最終的に最も貴重な資産を保護することで、従業員、顧客、社会を保護するように設計された概念です。

テクノロジーのニーズをビジネス上のメリットに変換します。デジタル変革、クラウド移行、テレワークへの対応などのビジネス計画がゼロトラスト計画によってどのように実現されるかを示します。

— Forrester、A Practical Guide to a Zero Trust Implementation

完全移行への道のり

ゼロトラストの戦略とロードマップを取締役会にかける

Page 16: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 16

ステージングの前提条件

ネットワークのステージング前の状態として、次の 条件が想定されています。

• 現在の境界内に所在するアプリケーションとユーザーは IP 経由で相互に直接到達できる

• 現在の境界内に Akamai Enterprise Application

Access Connector をインストール済みである

• 最終的に社内アプリケーションを配置する隔離

VLAN を作成済みである

• その隔離 VLAN に Akamai Enterprise Application

Access Connector をインストール済みである

• 移行中は、オフプレミスのエンタープライズユーザーの VPN を導入したまま維持し、移行されていないアプリケーションに到達できるようにする

これらの前提条件が満たされていれば、完全移行までの各アプリケーションの実施段階について、検討を始めることができます。これらの段階は非常に細かく分割されているため、移行のプロセスに慣れてきたら、いくつかの段階を組み合わせることも可能です。

Page 17: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 17

このユーザーは、アプリケーションが Enterprise Application Access を通じて初めてアクセス可能になったときに、そのアプリケーション機能の整合性を検証する役割を担います。標準的なふるまいと特殊な場合の両方をテストするために、アプリケーションの操作上の意味について十分な知識を持ったユーザーである必要があります。

何らかのセキュリティ機能やパフォーマンス機能が追加されるので、これらのユーザーには、そのセキュリティが期待どおりに動作しているかどうかやパフォーマンスが本当に改善されているかどうかのテストに関するバックグラウンドも必要です。

アプリケーションの数が多い組織の場合は、一般的なパフォーマンステストや一定のセキュリティチェックなど、アプリケーション固有ではない標準機能を、人による綿密な監視を必要とせずに定期的かつ自動的に実行するツールへの投資を検討してください。このようなツールでの実行に適したセキュリティチェックには、SQL インジェクション、クロスサイトスクリプティング、ボット検知、コマンドインジェクションなどがあります。

これは、Enterprise Application Access を最初に公開する Production ユーザーのグループであり、ネットワーク境界外でアプリケーションにアクセスする正規ユーザー全員から構成されます。このグループは動的な形式で運用されます。つまり、ユーザーがオフプレミスに移動すると、そのユーザーは動的にこのグループに参加し、ネットワーク境界内に戻ると、このグループから動的に離脱します。

これは、Enterprise Application Access を最後に公開する Production ユーザーのグループであり、そうすることで、アプリケーション移行がすべてのユーザーに対して完了します。このグループは、このアプリケーションにアクセスするネットワーク境界内の正当なユーザー全員で構成されます。上記の外部ユーザーグループと同様、このグループのメンバーは動的に変わります。ユーザーは、社内ネットワークの境界内に入ると自動的にこのグループに参加し、 境界から出ると「外部ユーザー」グループに参加します。

Akamai でのアプリケーションのステージング過程の一環では、選ばれたユーザーグループにゆっくりとフェーズ移行する必要があります。

アプリケーションごとに大まかに 3 つのユーザーグループを定義することをお勧めします。

テストラボ

外部ユーザー

内部ユーザー

ユーザーの分類

Page 18: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 18

ユーザーの分類方法

Akamai は、段階的な移行の際に、アクセスプロキシとして Akamai Enterprise Application Access 製品を利用します。Akamai では、DNS を使用して分散ネットワークにアプリケーションをオンボーディングしています。アプリケーションホスト名は、ユーザーを

Akamai プラットフォームにルーティングするため、CNAME を Akamai にします。

これにより、ユーザーによるホスト名検索が Akamai

への CNAME チェーンに該当すると、そのユーザーは Akamai のグローバルネットワークに転送されます。検索結果として元の内部 A レコードが返される場合、そのユーザーは引き続き従来の境界方式でアプリケーションにアクセスすることになります。このアーキテクチャは、どのグループが CNAME チェーンに従い、どのユーザーに内部 A レコードが提供されるのかを制御することで、さまざまなユーザーグループを各アプリケーションの Enterprise Application

Access にフェーズ移行する方法として活用できます。

これを実現するために、スプリットホライズン DNS

とも呼ばれる DNS ビューを使用して上記の 3 つのユーザーグループを定義します。DNS ビューとは、まったく同じホスト名を照会する複数のユーザーに、それぞれのソース IP に応じて、まったく異なる答えを提供できるようにする手法です。たとえば、中国のユーザーが www.foo.bar を照会すると、別個の IP を 1 つ受け取りますが、英国のユーザーがまったく同じホスト名を照会しても、まったく異なる IP を受け取ることになります。

この方法は、さまざまなユーザーグループを送信元となる CIDR ブロックで編成することで利用します。すべてのテストラボユーザーは 1 つの CIDR ブロックに存在し、内部ユーザーは社内ネットワーク全体を定義する CIDR ブロック内に存在し、外部ユーザーは、最初の 2 つのグループと一致しないすべての IP アドレスが送信元となります。

エンタープライズが最新環境に展開しているすべての一般的な DNS サーバーで、この機能がサポートされています。それでは、各種ユーザーグループを分割する方法が分かったので、実際のアプリケーション展開の段階について説明していきます。

以降のページでは、アプリケーションの展開を成功させるための 8 つの段階と、各段階で考慮する必要がある要素について説明します。

特定のアプリケーション要件や移行方法についてのご質問は、弊社の貴社担当営業にお問い合わせいただくか、こちらから、Akamai セキュリティエキスパートにご相談ください。

このユーザー分類方法は、今日のエンタープライズが現在の環境に導入している一般的な DNS サーバーで対応できます。

アプリケーション展開段階

Page 19: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 19

1. アプリケーション事前確認段階

この段階では、導入したアクセスプロキシの要件をアプリケーションが満たしていることを確認します。Akamai Enterprise Application Access の場合は、アプリケーションのプロトコルがサポート対象であることを確認します。

検討事項:

リモートアクセスに関して最も問題となるアプリケーションはどれか?

このアプリケーションを使用するユーザーグループはどれか?

そのアプリケーションはどこにホストされているか?

どのような仮想環境が使用されているか?

概念実証(POC)が成功した場合の結果はどのようなものか?

クライアントレスプロトコルには、HTTP、HTTP(S)、RDP、または SSH が含まれます。TCP および UDP のアプリケーションは、クライアントでサポートされます。

Page 20: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 20

2. アクセスプロキシ準備段階

次の段階では、アクセスプロキシを設定して、アプリケーションとその具体的なセキュリティおよびアクセ ス 権 が 認 識 さ れ る よ う に し ま す。Akamai

Enterprise Application Access の場合は、これをクラウドで設定します。

検討事項:

アウトバウンドプロキシはあるか?

ユーザー認証にはどのディレクトリソースを使用するか?

アプリケーションに MFA が関連付けられているか?

オンプレミス、クラウド、パブリックアプリケーションに SSO を 拡張するか?

設定は即座にすべての Akamai Enterprise Application

Access Connector および Akamai プラットフォーム全体にプッシュされ、すべての Akamai POP がエンドユーザーにサービスを提供できるようになります。

Page 21: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 21

3. テストラボ登録段階

当該アプリケーションがアクセスプロキシに認識されれば、ユーザーのオンボーディングを開始できます。Akamai Enterprise Application Access プロキシを使用する場合は、この段階で前述の DNS ビューを変更し、テストラボのグループメンバーが特定のアプリケーションホスト名を検索すると、Akamai に

CNAME されるようにします。

この作業の直後から、テストラボのメンバーは、特定のアプリケーションにアクセスしようとするたびに Akamai のグローバルネットワークに誘導されるようになります。

この段階で、テストラボのメンバーは、認証が正しく機能していること、多要素認証が適切に設定されていること、すでにオンボーディングされている他のすべてのアプリケーションで SSO が機能していることを確認する必要があります。さらに重要なこととして、この段階では、アプリケーション機能の正確性も詳細にテストする必要があります。

検討事項:

現在ユーザーはこれらのアプリケーションにどのようにアクセスしているか?

テストするユーザーグループはどれか?

成功したかどうかはどのように判断するか?

ユーザーのテスト期間は?

Page 22: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 22

アプリケーション展開段階

4. セキュリティ強化段階

テストラボのメンバーが Enterprise Application

Access を使用してアプリケーションに安全にアクセスできるようになったら、次は、従来の境界モデルでは不可能だった高度なセキュリティ機能を作動させることについて検討します。このセクションでは、Akamai Enterprise Application Access プロキシと連携させて使用できる特定の Akamai セキュリティ製品について取り上げます。ただし、これらの製品を使用するかどうかを問わず、一般的な推奨事項と導入段階はそのままです。

WAF 機能を利用するためには、最低限 Akamai Kona

Site Defender 製品を有効にすることをお勧めします。この製品の連携後、当該アプリケーションに対する

SQL インジェクション、クロスサイトスクリプティング、およびコマンドインジェクションの攻撃が WAF

プラットフォームによって拒否されることを、テストラボのメンバーが確認します。

この段階で、アプリケーションオーナーは、シンプルかつ非常に強力なセキュリティ追加策として、ボット対人の検知も検討する必要があります。当該アプリケーションが API サーバーではなく、プログラムでアクセスできない場合は、Akamai Bot Manager 製品を使用すれば、この機能を有効にできます。高度な分析により高い確度で人であると判断できた場合以外は、接続を拒否するようにプラットフォームに指示することが可能です。これは、正規ユーザーのセッションの背後でなりすましを行うマルウェアや他の巧妙な持続的脅威を遮断するのに大いに役立ちます。

この段階では、当該アプリケーションを管理対象デバイスに限定する必要があるかどうかも決定します。管理対象デバイスに限定する場合は、エンドデバイスに証明書が展開されていれば、パブリック認証局の証明書を Akamai Enterprise Application Access にアップロードすることで、管理対象外のマシンからの接続はすべて拒否することができます。

Page 23: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 23

アプリケーション展開段階

最後に、地域や IP ベースの制限も有効にすることができます。使用すべき具体的な CIDR ベースの許可リストや拒否リスト、またはアクセスを拒否すべき地域が分かっている場合は、この時点でそれらを有効にしてテストすることが可能です。

所有するアプリケーションのセキュリティが確保されたら、所有していないアプリケーション、特にインターネット上にあるアプリケーションについて検討することをお勧めします。G Suite や Dropbox のような

Web ベースの企業アプリケーションにアクセスしているトラフィックの保護はどうすればよいでしょうか。クラウドベースのセキュア Web ゲートウェイである Akamai Enterprise Threat Protector を有効にすることをお勧めします。これにより、すべてのインターネットトラフィックをプロキシして、分析や検査を実行できます。

有効にする機能が何であろうと、セキュリティオプションが機能していることだけでなく、アプリケーションの正確な機能を阻害していないことも、この段階でテストラボグループが確認しなければなりません。

検討事項:

地理的制限は必要か?

ユーザーに DNS をどのように提供するか?

導入されているモバイルデバイス管理(MDM)ソリューションはどのようなタイプか?

Page 24: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 24

5. パフォーマンス強化段階

アプリケーションがオンボーディングされ、セキュリティが実装されたら、次は、パフォーマンスが不十分かどうかを検討する必要があります。従来の境界ベースのアクセスおよびセキュリティでは、データセンターの所在地や、そのエンタープライズのブランチ間のリンクによって、パフォーマンスに制約が生じることがよくありました。

これらの問題を緩和するためにオンプレミスキャッシングなどの機能を導入できる場合もあります。ただし、キャッシングがパフォーマンスに最大限の効果をもたらすのは、エンドユーザーに最も近い場所で実施したときであるため、従業員がオフプレミスとなり移動する場合は期待はずれの結果となります。

この段階では、アプリケーションにパフォーマンス向上が必要かどうかを評価し、必要な場合は、キャッシングなどの利用可能な技術を活用します。Akamai

Enterprise Application Access を使用している場合は、Ion 製品を通じて Akamai の CDN を有効にすれば、確実にパフォーマンスが向上します。この方法では、世界各地にある Akamai の約 25 万台のサーバーでキャッシングを実行できるので、エンドユーザーが

どこにいても、クラス最高のパフォーマンスを提供できます。さらに、この機能を有効にすると Akamai ネットワークにアクセスできるようになり、前方誤り訂正(FEC)、ルート最適化、およびパケット複製によってパケットロスがほぼゼロになり、パフォーマンスベースのルーティングが可能となります。

ネットワーク境界の外にいるときのパフォーマンス改善度を相対的に評価するのに最も適した立場にあるのは外部ユーザーなので、後述する外部ユーザー登録段階が行われるまで、この段階を延期してもかまいません。

いずれにしても、パフォーマンスの改善を正確に評価するために、この段階で、アプリケーション登録前にパフォーマンスの測定を行うことをお勧めします。測定には、ブラウザープラグイン、ウォーターフォールグラフ、またはサードパーティ製のパフォーマンス監視サービスなどを使用できます。

検討事項:

ユーザーはどこにいるか?

アプリケーションはどこにあるか?

Page 25: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 25

この段階まで到達すると、アプリケーションがオンボーディングされ、Akamai Enterprise Application

Access を介してアクセス可能になっています。セキュリティが大きく強化され、任意でパフォーマンスがさらに向上し、内部のテストラボによるテストを通じて期待どおりに機能するという確信が得られているはずです。

いよいよ、アプリケーションをより多くのユーザーに公開するときです。この時点で、外部ユーザーへの移行段階に進むことをお勧めします。外部ユーザーは、このアクセス方式によって最終的に VPN が削除されるユーザーです。また、パフォーマンス問題の影響を受けることが最も多いユーザーであり、アプリケーションやデータをリスクにさらすような最も敵対的

な環境にいるユーザーでもあります。このユーザーグループに、より優れたパフォーマンスとセキュリテ ィ を 適 用 で き る こ と は、Akamai Enterprise

Application Access の最大の利点であり、これはすぐに明らかとなります。

この段階を開始し、DNS ビューを変更する前に、ユーザーが移行に驚かないように通知しておくことをお勧めします。この時点までの設定がすべて適切に行われていれば、パフォーマンス向上を除いて、ユーザーが移行に気付くことはほとんどありません。しかし、事前に通知しておくことで、ユーザーが機能の正確さについて特に注意を払うようになるため、何らかの誤りがあった場合にその理由に気付くことができ、適切な管理者に連絡する用意ができます。

検討事項:

現在ネットワークにアクセスしているサードパーティはあるか?

リモートアクセスはどのように提供されているか?

既存のモデルの課題は何か?

必要性が最も低いのにアクセス権が最も大きいリモート・ユーザー・グループはどれか?

6. 外部ユーザー登録段階

Page 26: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 26

この段階では、外部ユーザーの登録から一定期間が経過し、運用の不具合はすべて対処されています。この時点で、DNS ビューに明示的に設定していたアプリケーションへの参照をすべて削除し、これを CNAME

エントリとして共通ビューに追加できます。これにより、すぐに全ユーザーがこのアプリケーションへのアクセス時に Akamai Enterprise Application Access プロキシを介するようになります。

この段階では、外部ユーザーへの通知に使用したすべての手続きを内部ユーザーにも適用する必要があります。エラーや誤った構成は、先の 6 つの段階を通してすべて検出され、是正されていることが見込まれています。この想定が正しければ、この時点でアプリケーションは Akamai Enterprise Application Access に正常に移行され、すべてのユーザーが簡単で高速かつ安全なアクセスの恩恵を享受しているはずです。

検討事項:

ほかにどのグループがこのアプリケーションへのアクセスを必要としているか?

現在、リモートアクセスをどのように提供しているか?

既存のモデルの課題は何か?

これらの特定ユーザー以外にこのアプリケーションへのアクセス権を持つユーザーグループはあるか?

7. 内部ユーザー登録段階

Page 27: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 27

8. VLAN 移行段階

内部ユーザー登録段階で、ある程度の期間が経過すれば、最後の段階として、アプリケーションを隔離

VLAN に移行できます。これを行わないと、たとえすべての正規ユーザーが DNS を使用し Akamai

Enterprise Application Access 経由でアクセスしても、アプリケーションサーバー自体は引き続き IP アドレスで直接到達可能であるため、ネットワーク境界内のマルウェアに対して脆弱です。

この最終段階では、IP による直接アクセスの手段が取り除かれ、実質的にアクセスプロキシ以外からアプリケーションが隔離されます。

これが完了すると、アプリケーションは正式かつ完全に Akamai Enterprise Application Access に移行されたことになります。

検討事項:

ネットワーク制御はどのように実施されているか?

現在、これらのアプリケーションにはどのような種類のネットワークレベルアクセスが存在するか?

これらのアプリケーションはセグメントに分けることができるか?

ネットワークの関係者は誰か?

Page 28: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 28

ステージング後の作業

すべてのアプリケーションが Enterprise Application

Access に移行されたら、エンドユーザーシステムから VPN クライアントを完全に削除する作業に着手できます。

また、すべてのアプリケーションアクセスがゼロトラストのアクセスモデルに移行されているので、内部ユーザーのネットワークをゲスト Wi-Fi に変換する措置を採ることも検討できます。

最後に、この段階では、データセンターに戻る接続を高度な DDoS 攻撃から防御することも検討する必要があります。ここで役立つソリューションとして

Akamai Prolexic 製品があります。

まとめと次のステップ

従来のハブ・アンド・スポーク型ネットワーキングアーキテクチャと「堀と城」方式のセキュリティ境界を使用していたのでは、現在のようなクラウドとモバイルの世界に効果的にパフォーマンスとセキュリティを提供することはできません。これは、脆弱な状態に陥ることがないように、すべての企業が取り組み始めるべき問題です。今や、企業のセキュリティ侵害の原因の第 1 位は、安全なエンタープライズ・セキュリティ・アーキテクチャに移行していないことであり、ひたすら悪化の一途をたどっています。簡単に言うと、境界の内側は安全ではないということです。なぜなら、境界自体がもはや存在しないからです。

ゼロトラスト・アーキテクチャへの移行に着手するためにはどうすればよいのか?Akamai のクラウド・セキュリティ・サービスを組み合わせることで、包括的なゼロトラスト・アーキテクチャを構築できます。これにより、クラウドネイティブな世界で安全なアプリケーションアクセスを実現できるだけでなく、クラウドを活用して社内ネットワークの必要性をほぼ完全に排除することもできます。

Akamai の高度な分散 ZTNA ソリューションとグローバルな Akamai Intelligent Edge Platform の力を活用すれば、信じられないほど簡単な方法で、最終的に境界のない世界へと移行できます。アプリケーションを段階的に移行し、移行のリスクプロファイルをゼロに近づけ、22 年間もの長期にわたって Akamai が実績を積み重ねてきたパフォーマンスソリューションやセキュリティソリューションを活用できます。

お客様がゼロトラスト・アーキテクチャへの移行を安心して進めていくことができるように、Akamai は移行の各段階でお客様をサポートします。アプリケーションとデータへのアクセスを提供するだけでなく、それを管理しやすい方法で実現し、高水準のセキュリティとパフォーマンスを維持できるアーキテクチャへとネットワークを移行するためにお手伝いいたします。

Akamai のセキュリティエキスパートとともに、ゼロトラストへの段階的な移行手順をお客様の状況に合わせてカスタマイズできます。30 分間のワークショップにお申込みください。現在の状態、望ましい最終状態、ビジネスの優先順位、脆弱性、主な懸念事項についてお話しいたします。また、akamai.com/zerotrust でも詳細をご確認いただけます。

Page 29: A Blueprint for Zero Trust Architecture - Akamai...Architectural Visualization 14 Getting from A to B 15 Pre-Staging Assumptions 16 User Grouping 17 User Grouping Methodology 18 Application

akamai.com | 29

執筆者

Charlie Gero、Chief Technology Officer、Enterprise and Advanced Projects

Group、Akamai

Charlie は、Akamai Labs の共同設立者であり、エンタープライズおよびクラウドネットワーキング分野の研究開発を率いています。特にパフォーマンス、アクセス、セキュリティに関する取り組みに力をいれています。

Akamai は世界中の企業に安全で快適なデジタル体験を提供しています。Akamai のインテリジェントなエッジプラットフォームは、企業のデータセンターからクラウドプロバイダーのデータセンターまで広範に網羅し、企業とそのビジネスを高速、スマート、そしてセキュアなものにします。マルチクラウドアーキテクチャの力を拡大させる、俊敏性に優れたソリューションを活用して競争優位を確立するため、世界中のトップブランドが Akamai を利用しています。Akamai は、意思決定、アプリケーション、体験を、ユーザーの最も近くで提供すると同時に、攻撃や脅威は遠ざけます。また、エッジセキュリティ、Web/モバイルパフォーマンス、エンタープライズアクセス、ビデオデリバリーによって構成される Akamai のソリューションポートフォリオは、比類のないカスタマーサービスと分析、365 日 /24 時間体制のモニタリングによって支えられています。世界中のトップブランドが Akamai を信頼する理由について、www.akamai.com、blogs.akamai.com および Twitter の @Akamai で紹介しています。全事業所の連絡先情報は、www.akamai.com/locations をご覧ください。公開日:2021 年 2 月。