Barracuda CloudGen Accessハンズオン

是非、ZTNAってどんなものか知っていただきたいと思います。 実際にZTNAのソリューションである、Barracuda CloudGen Access（以下CGA）の設定を使って紹介していこうと思います。

注意として、現在（2021/1中）未発売の製品なものと、今まさに、機能のフィードバックを行っているところなので、今後販売される際は仕様が変わっているかもしれませんのであしからず。

Barracuda CloudGen Access

もともとFydeというZTNAのスタートアップ製品をBarracudaが2020年11月に買収しゼロトラストソリューションとして新しくラインナップに加えた製品となります。

バラクーダ、Fyde、およびBarracuda CloudGen Access

構成について

CGAをセットアップする際に必要なコンポーネントを確認します。 実際は以下のように、App（デバイス）、Access Proxy、Fyde enterprise consoleの3つが必須コンポーネントとなるので、それぞれを用意する必要があります。

fydeマニュアルより（https://fyde.github.io/docs/)

なお、実環境にセットアップするのは、Access Proxy（仮想アプライアンス）のみで、コンソールはクラウドのサービス、Appについてはデバイスへインストールするものとなります。

なかなか珍しい？ダイレクトアクセス

ネットワークダイアグラムを見ることで、CGAの構成が概ね理解できると思います。

多くのZTNA製品については、クラウド上のゲートウェイと拠点内のプロキシがトンネル接続することで、一旦ユーザーはどんな環境であっても、クラウドのゲートウェイを経由する必要がありました。結果的に、外部にプロキシサーバーを公開せずに、クラウドのゲートウェイとのセッションによって、外部からのリモートアクセスを実現しています。

CGAは、拠点に設置されるプロキシにたしてmTLS通信を直接おこなうような構成のため、プライベートアクセスの際、クラウドを経由せず（なるべく遅延が少ない）方法でアクセスできる可能性があります。その反面、プロキシサーバーを従来のVPNのように公開（グローバルIPアドレス）、ポートフォワーディングが必要となります。

ゼロトラストアーキテクチャのコンセプト

ZTNAのコンポーネントとしては当たり前ですが、コンソール（プロキシオーケストレーター）とプロキシ（データプレーン）がきちんと分離されています。 また、プロキシはコントロールプレーンでトークンを発行することでセットアップが完了するので、管理者が制御されたプロキシを検証する仕組みが搭載されています。

実際にプロキシに払い出すトークンの生成画面を見ると難しい設定は不要です。プロキシの名前、ロケーション、ホストアドレス、ポート番号を入力し、トークンを作成するだけです。

プロキシの登録とトークンの払い出し

ローカルに設置するプロキシを作る

マニュアルを見る限り、とても小さなリソースだけが必要のようです。更に、AWSを始めベアメタル、バーチャルマシン、Dockerとほぼあらゆるマシン上で動くようですので、中・小規模の環境でも導入しやすいです。さらにシングルボードコンピューターにインストールしても十分動く可能性があります。

実際インストールはとても簡単です。仮想マシンをインストールし、以下スクリプトを流し込むだけ

---

あとはインタラクティブな指示に従って、ポート番号、トークンのリンクを貼り付けるだけとなります。

[XXX@localhost]# sudo bash -c "$(curl -fsSL https://url.fyde.me/install-fyde-proxy-linux)" 
2020-11-24 15:23:53 [INFO] Please provide required variables 
Specify Fyde Access Proxy public port (443): 
Paste the Fyde Access Proxy enrollment link (hidden): 
Specify Redis host (only required for HA architecture): 
2020-11-24 15:26:49 [INFO] Check for yum lock file 
2020-11-24 15:26:49 [INFO] Install pre-requisites 
Failed to set locale, defaulting to C 
Last metadata expiration check: 0:09:05 ago on Tue Nov 24 15:17:45 2020. 
Package chrony-3.3-3.el8.x86_64 is already installed.

---

検証で出来上がった構成

とてもシンプルです。一般的なZTNAと同様に、プライベートアクセス時はプロキシのIPアドレスでSNATされる形になります。

アクセス制御の方法

ポリシーの書き方このようになります。 現時点では、必ずアクセスリソースに対して、パブリックホスト名を設定する必要があります。これにより、プライベートネットワーク内のアプリケーションやサーバーにアクセスする際は、このパブリック名を使ってアクセスする必要があるということです。

ワイルドカードでも作成可能

リソースアドレスに対して、一つずつホスト名を定義するのはさすがにきついですよね。CGAでは予めホスト名アクセスができるものについては、ワイルドカードでの指定が可能です。

実際にリモートからアクセスしてみる

例えば、リモート先からプライベートネットワーク内のサーバーにアクセスして見ました。リソース名で定義したパブリックホスト名に対してアクセスすると問題なくアクセスができます。

ただし、ワイルドカードで指定した場合、きちんとドメイン名まで入力する必要があります。

アクセスする前に、nslookupを使って許可されたリソースへの名前の解決結果を見てみるとこのようになります。

実際にはリアルなローカルIPへアクセスしているのではなく、一旦Cloud（CGA）側に問い合わせを行い、中継するためのIPを返信されているようです。 そのため、仕組みとして一旦アクセス制御として、ルールを作成し、ホスト名がないとインターネット越しにアクセスができないような作りになっていると思います。

ブラウザを使った、プライベートネットワークへアクセスすることができるようになります。

ユーザーの追加

ユーザーDBはローカル（クラウド上に手動登録）か、クラウドのディレクトリサービスと連携ができそうでした。

ユーザー名、メールアドレス、電話番号、所属するグループを登録します。 ユーザー登録時に招待状を送信することも可能で、ユーザーの利用を無効化することもできます。

ゼロトラスト的な要素

ZTNAと一般的なリモートアクセスのもっとも大きな違いとしては、複数のコンテキストを検証することにあると思います。CGAではここに書いてあるとおり、RBAC（ロールベースアクセスポリシー）機能を始め、デバイス特有の状態を検証し、アクセス制御する機能が搭載されていました。

このようなデバイスの状態を検証する機能は従来のリモートアクセスVPNには備わっていない機能です。

ユーザーやグループ単位で検証項目を変える（RBAC）

アクセス設定では、グループに対して検証する項目をチェックするだけととてもシンプルです。なおデバイスのチェックはOSによって制御できる項目が異なります。

ユーザーの招待

ユーザーへの展開はとても簡単です。スマホでもPCでも基本的に同じ方法で設定が行われます。 ユーザーは自身が招待されたメールを開き、スタートをクリックすることで、自身のアクセス環境がエンロールメントされることになります。

メールに含まれるリンクは、ユーザーごとに一意のリンクが生成されているため、このリンクは正しくユーザーに届ける必要があります。

エンロールメントが可能な回数や期間は制限することができますので、不正に使いまわしされないように制御することもできそうです。

キャッチーなアプリケーション画面

テーマは忍者？なんでしょうか。アプリケーションに表示されるグラフィックはとても可愛らしいです。セットアップ方法はすべてのデバイスで共通の方法です。

ZTNAの環境にに接続するかしないか。それだけです。

これからのゼロトラストアクセスでは、どれだけ常時つないだ状態にできるかが重要だと思います。ユーザーが自身のロケーションを意識して、社内だったら無線LAN、社外だったらVPNと切り替えるのではなく、常にゼロトラストアクセスでユーザー、デバイス状態を検証し続けることが大切です。

CGAは、接続を有効にしておくだけで、パブリック、プライベートのアクセスを監視、制御し続けます。（有効にすることで忍者が一生懸命働いてくれています）

エージェントによってデバイスの情報を収集できます。

リモートアクセスVPNのように、送信元のデバイスを特定することができないことはありません。CGAがインストールされたデバイスの情報はこのようにどんなデバイスが登録されているか見えるようになります。そのためテレワーク中に私物のPCを使ってアクセスするような行為も見分けれる可能性が高まります。

しっかり見て、しっかり情報を収集

もはやMACアドレスで制御する時代ではないので、きちんとユニークなデバイスIDを収集することが重要です。 デバイス、ユーザー、送信元を検証することがゼロトラストアクセスの基本となります。

Fydeが提供する危険なアクセスをブロックする仕組み

CGAは単純にプライベートアクセスへのVPN機能を提供するだけではありません。 CGAはDNSを使って、ユーザーがアクセスしようとしているサイトを事前にチェックすることができます。危険なアクセスを試みた時点で、危険なDNSを返さないという方法で保護することができます。

DNSフィルタのメリットはSSL通信であっても、接続先の検証ができるというという点です。SWGの場合はHTTPSのヘッダーをチェックする場合はSSLインスペクションが必要になりますが、DNSフィルタリングによってより手軽に悪意のあるサイトへのアクセス制御が可能です。

手動でのブラックリスト、ホワイトリストも作成可能

手動で予めリストを作成すれば、禁止されたサイトへのアクセスも制御できます。

ユーザーでも個別のフィルターや広告ブロックなどの調整が可能

広告やトラッカー、マイニングサイトにおいては、ユーザーの権限で利用するかしないかを選択できます。効率よくWebサイトをアクセスするために、とても便利な機能です。

見たくない広告を排除したり、無駄にリソースを消費するサイトへのアクセスをブロックするだけでも、在宅ワークの効率は上がると思います。

ハンズオンを通して

紹介させていただいたとおり、ZTNAを展開するにあたって、設定上特に難しい部分は見つかりませんでした。特にプロキシの展開についても、クラウド側でトークンを作成し、コピー＆ペーストで貼り付けるだけなのでとても簡単です。 クライアント（アプリ）の展開も、基本的にユーザー自身でインストールする想定なので、メールに送られた招待状をクリックするだけで、後はウィザードに従ってインストールが完了します。

このようにZTNAは従来のフォーマルなリモートアクセスVPNと比べて、カジュアルな印象がありながら、きちっとデバイスの検証やRBACといったより精度の高いセキュリティ制御を実装している点はユーザー側としても監視されているという雰囲気も感じにくいかもしれません。

今後このようなZTNAソリューションがリリースされるとして、引き続き以下のポイントに注意してみてはいかがでしょうか。

• アクセスリソースの設定（アクセスルール）
• プロキシの展開のしやすさと汎用性
• 認証サーバーとの連携やユーザーの登録
• ユーザーの使い勝手

アプライアンス型のVPN装置のように、VPNのスループットやトンネル接続数、またデジタル証明書の配布など、最終的な構成を考えることなく、スモールスタートし、スケールアウトできるのもZTNAの特徴だと思います。

まとめ

いかがでしょうか。ZTNAの導入イメージは付きましたでしょうか。リモートアクセスVPN方式とZTNA方式を迷っている場合に参考になればと思いました。

急遽在宅ワークも増えて、自宅からアクセス制御をどうするべきか。ZTNAはそんな環境において、パブリック、プライベートアクセスの両方を同時に制御するための安全機能が搭載されています。 パブリックとプライベートの通信をデバイス側できちっと分離して、社外へのアクセスの安全性を担保しながら、なるべく社内側に引き込む通信量を減らすことで、在宅ワーク時のパフォーマンスを上げる仕組みがとても注目されています。

セキュリティの点でも、RBACや危険なデバイスの制御し、なりすましデバイス、ユーザーを防ぐことも急務です。 ZTNAはこれからの在宅ワークにおける、ネットワーク制御の部分において、ユーザー主体と考えると、重要な要素として考えられるソリューションの一つだと考えています。