- ライター：片岡 武義
- ネットワンシステムズに入社以来、セキュリティ製品担当として、主にCisco製品の評価・検証・技術サポート業務に従事。検証では、オンプレ環境やパブリッククラウド(AWSやAzure)環境などお客様のニーズに沿うよう考慮した形での検証を心がけています。
目次
リモートワークの普及に伴い、企業がリモートでの労働環境を提供する上でいくつかのセキュリティリスクや企業課題が出てきています。
はじめにその主なセキュリティリスクと課題について簡単に説明します。
セキュリティリスクについて
従業員が自宅や公共の場所からアクセスすることで、データ漏洩やサイバー攻撃のリスクが高まっています。
そのため、そのセキュリティリスクに対応するため、データ保護、プライバシー確保、厳格なアクセスポリシー、ウィルス対策などが求められており、具体的な対策として「データ暗号化」「データ漏洩防止（DLP）」「厳密なアクセス管理」「マルウェア対策」などの高度なセキュリティ対策が求められるようになっています。
企業課題について
これらのセキュリティ対策を行うためには、従業員に対して定期的なセキュリティ教育と訓練を実施し、セキュリティ意識を高めることが不可欠となっています。
また、高度なセキュリティ対策を導入し、定期的なアップデートやパッチ適用等を行うことも不可欠となっています。
これらの対策には、高度なセキュリティ対策製品の導入以外にも、高度な技術をもった人材確保も求められるようになっており、昨今の人で不足がより深刻化し、企業として抱える課題が増加しています。
今回はこれらのセキュリティリスクと企業課題に対応可能なCisco Secure Accessについて一部の主要な機能を試してみましたので、その内容を紹介します。
Cisco Secure Accessの主な機能について
まずは、Cisco Secure Accessで利用可能な主な機能を説明します。
１．セキュアプライベートアクセス(以下、SPA)
SPAは、社外から社内にある内部情報向けにセキュアに通信することを可能とします。
内部情報へセキュアな通信を可能とするため、下記のような機能が提供されます。
1-A) Agentless Zero Trust Network Access(Agentless ZTNA)
1-B) Agent Zero Trust Network Access(Agent ZTNA)
1-C) Virtual Private Network-as-a-Service(VPNaaS)
1-D) デバイス健全性管理
※ZTNA機能は、認証機能により、アクセス元が誰かを明確にし、そのユーザーに与えられている最低限のアクセス権限を与え、不必要なリソースへのアクセスを厳格化する等が可能な機能です。また通信も暗号化されるためデータ保護、厳格なアクセスポリシーが提供可能となります。
※VPNaaS機能は、従来のVPN機能をクラウド環境で利用可能としたものです。ZTNA機能導入時に対象の既存システムがやプロトコルの特性上、ZTNA機能に未対応だった場合などでもこのVPNaaS機能を利用することで既存のシステムへのアクセスを維持することなどが可能です。
２．セキュリティインターネットアクセス(以下、SIA)
SIAは、社内ユーザーやリモートユーザーがインターネットにセキュアに通信することを可能とします。
セキュアな通信を可能とするため、下記のような機能が提供されます。
2-A) DNS Security
2-B) Secure Web Gateway(SWG)
2-C) サンドボックス解析に対応したマルウェア対策
2-D) Cloud Access Security Broker(CASB)
2-E) データ漏洩防止(DLP)
2-F) クラウド型ファイアウォール(CDFW)
2-G) Intrusion Prevention System(IPS)
2-H) SaaSマルウェア対策(Cloud Malware Protection)
３．その他
3-A) 拠点間通信
3-B) SD-WAN連携
3-C) Digital Experience Monitoring
これらの機能を利用することでセキュリティリスクや企業課題への対応が可能になります。
私の方で今回これら機能の動作検証を実施致しましたので、その検証構成や設定及び利用イメージが伝わりやすいよう画面キャプチャを交えてご紹介します。
尚、今回は、SPAの機能にフォーカスしてご紹介します。
検証構成
SPAの機能は、〈図1〉の構成にて実施しました。
〈図1〉
上記構成にて下記の機能を利用します。
1.ZTA(Brower)で社内イントラにブラウザ(Firefox)でアクセスして「1-A) Agentless ZTNA」と「1-D) デバイス健全性管理」機能の確認をします。
2.ZTA(Brower)で社内イントラにブラウザ(Chrome)でアクセスして「1-A) Agentless ZTNA」と「1-D) デバイス健全性管理」機能の確認をします。
3.ZTA(Client)で社内のRDPサーバへRDPでアクセスし「1-B) Agent ZTNA」機能の確認をします。
4.VPN(Client)で社内ネットワークへ接続し、ネットワークの疎通性確認としてPingやファイル共有アクセスを行い「1-C) VPNaaS」機能の確認をします。
設定イメージ
1.最初にSecure Accessの下記全般的な設定をします。
・Secure Access接続時の名前解決用にDNSサーバアドレスを設定します。
・Secure AccessとAWS間のIPSEC接続設定をします。
・利用者PCからSecure Accessへ接続を行う際に利用するユーザIDとグループ情報をIdPから同期し、さらにSSOの設定をします。
2.Agentless ZTNAとデバイス健全性管理の設定イメージ
1)「リソース」→「セキュリティ設定」→「プライベートリソースグループ」にてPrivate Resource Groupを作成します。
2)「リソース」→「セキュリティ設定」にてPrivate Resourceを作成し、1)で作成したPrivate Resource Groupに紐づけます。
Private Resource Nameは、任意でそのリソースが何かを判別しやすい名称にします。
〈図2〉
Internally reachable address欄には、アクセス先リソースのFQDNやIPアドレス、プロトコル、ポートを指定します。
また、ZTNA機能を利用するため、「Zero-trust connections」にチェックを入れます。
Agentless ZTNAでは、Webの通信のみサポートしているため、社内イントラにアクセスする想定でWebの宛先を指定します。
〈図3〉
Publlic URL for this resource欄の「https://」から始まる欄には、社内リソースに外部からアクセスする際に使用するURLを指定します。任意の文字列を「.ztna.sse.cisco.io」の冒頭部分に入力することでパブリックに公開されたURLが出来上がります。
〈図4〉
3)「確保」→「Endpoint Posture Profiles」にてデバイス健全性管理の検疫ルールを作成します。
今回は、利用するブラウザを制限するための検疫ルール作成します。このルールによりブラウザがChromeを利用している場合のみアクセスが可能となります。
尚、このほかにも検疫ルールとしてOSの種類を限定することも可能です。またエージェントベースのZTNA機能やVPNaaSなどでは、さらに多くの検疫オプションが選択可能です。
〈図5〉
4)「確保」→「Access Policy」にて「誰が」「どのリソースに」アクセス可能かやどの「検疫ルール」を適応するか、さらには通信保護の観点で「IPS機能」の有無などのルールを作成します。
今回のルールは、Takeyoshi Kataokaのみがすべてのリソースにアクセス可能として設定しておりますが、アクセス先のリソースを特手の宛先のみに絞ることなども可能です。
〈図6〉
検疫ルールの選択では、3)で作成したルールを選択します。
〈図7〉
5)以上が基本的な設定となります。
3.Agent ZTNAの設定イメージ
1)「リソース」→「セキュリティ設定」にてPrivate Resourceを作成し、1)で作成したPrivate Resource Groupに紐づけます。
Private Resource Nameは、任意でそのリソースが何かを判別しやすい名称にします。
Internally reachable address欄には、アクセス先リソースのFQDNやIPアドレス、プロトコル、ポートを指定します。
今回は、Agentless ZTNAではサポートされていないWeb以外の通信としてRDP宛の通信を設定します。
〈図8〉
「Zero-trust connections」にチェックを入れ、「Client-based connection」をオンにします。
また、RDP接続先のRDPサーバのアドレスを指定します。
〈図9〉
2)「確保」→「Access Policy」にて「誰が」「どのリソースに」アクセス可能かやどの「検疫ルール」を適応するか、さらには通信保護の観点で「IPS機能」の有無などのルールを作成します。
3)以上が基本的な設定となります。
4.VPNaaSの設定イメージ
1)「繋ぐ」→「End User Connectivity」→「Virtual Private Network」→「Manage IP Pools」の項目にてVPN接続時に割り当てるPool IPを設定します。
2)「繋ぐ」→「End User Connectivity」→「Virtual Private Network」にてVPN Profileを作成します。
VPN Profile nameに任意の名称を指定します。
Default Domainでは、VPN接続後に所属するドメインを指定します。
DNS ServerではVPN接続後の名前解決に使用するDNSサーバを指定します。
さらにVPN接続時のプロトコルを指定します。今回は、内部DNSサーバが無いため、パブリックなグーグルのDNSを指定しています。またプロトコルには、TLS/DTLSを指定します。
〈図10〉
次に認証方式を指定します。認証方式には、クライアント証明書認証、SAML、Radiusなどが指定可能です。
今回は、SAMLでの認証を指定し、IdPとのメタデータやり取り用の設定を指定しています。
〈図11〉
Tunnel Modeを指定します。
ここでは、Secure Accessに接続するか、それともSecure Accessをバイパスするか指定します。
今回は、Secure Accessに接続し、社内リソースへのアクセスを目的としているため、「Connect to Secure Access」を選択します。あとは、スプリットトンネルの有無やVPNのタイムアウト時間等を指定します。
〈図12〉
3)以上が基本的な設定となります。
利用イメージ
1.Agentless ZTNAとデバイス健全性管理の利用イメージ
1)Agentless ZTNAは、ブラウザでアクセスします。
アクセス先のURLは、2-2)で設定を行った際に表示されていた下記URLです。
→「https://172browser-xxxxxxx.ztna.sse.cisco.io」
2)まずは、デバイス健全性管理の機能でブラウザの検疫ルールが動作するか確認するため、ブラウザFirefoxで「https://172browser-xxxxxxx.ztna.sse.cisco.io」へアクセスします。
3)SAML認証のため、あらかじめ設定しているIdPにリダイレクトされます。
4)ユーザー情報を入力し、認証します。
〈図13〉
5)検疫処理が行われ、検疫ルールに設定したブラウザ(Chome)が利用されていないためエラー画面が表示されました。
〈図14〉
6)今度はブラウザChromeで「https://172browser-xxxxxxx.ztna.sse.cisco.io」へアクセスします。
7)同様にSAML認証のため、あらかじめ設定しているIdPにリダイレクトされます。
8)ユーザー情報を入力し、認証します。
9)検疫処理が行われ、検疫ルールに設定したブラウザが利用されているため、社内イントラサイトへ正常にアクセスできました。
〈図15〉
2.Agent ZTNAの利用イメージ
1)ZTNAのAgentにて、アクセス元ユーザーを特定するための登録を行う必要があるため、Enrollを実行します。
〈図16〉
2)Enrollには、誰かを特定するための認証情報が必要となりますので、認証します。
〈図17〉
3)認証に成功するとEnroll完了となります。
Enrollが正常に完了していると「Zero Trust Access is active」と表示され、これでZTNAのエージェント機能が利用できます。
〈図18〉
4)Webの通信以外であるRDPで通信できるか検証するため、リモートデスクトップのアプリケーションにてRDPサーバの内部IPを直接指定して接続を実施します。
ZTNAのエージェントがCisco Secure Accessと繋がり、Cisco Secure AccessとAWS間がIPSECトンネルで接続されている状況のため、外部ネットワークからでもZTNAのエージェントによりRDPサーバへの疎通が可能となり、RDP認証用の画面が表示されました。そのため、認証情報を入力します。
→ 
〈図19〉 〈図20〉
5)認証後、RDPでの接続ができました。
〈図21〉
3.VPNaaSの利用イメージ
1)Cisco セキュアクライアントでAnyConncet VPNの「接続」を選択します。
接続選択後、SAML認証の設定により、IdPへの認証画面が表示されますので、認証を実施します。
その後認証に成功するとAnyConnect VPNに「接続されています」の表記がされます。
→ 
〈図22〉 〈図23〉
2)ネットワーク的に疎通可能な状況にあるサーバへpingやファイル共有でのアクセスをします。
〈図24〉 〈図25〉
3)Pingテストへのリプライが正常に行われ、ファイル共有も格納なことが確認できました。
さいごに
これまでもクラウドセキュリティとして「Cisco Umbrella」という製品があり、この製品を利用することで、セキュアなインターネットアクセスを可能としておりました。ただし、「Cisco Secure Access」のように社内リソースへアクセスすることを目的としてクラウド側にVPNを接続するVPNaaSやアプリケーション毎の細かい制御を可能とするZTNA機能は搭載されておりませんでした。
今回検証したこれらの機能が「Cisco Secure Access」加わることにより、冒頭ご紹介した「セキュリティリスク」や「企業課題」に対応できる製品と言えると思います。
尚、「Cisco Secure Access」には、今回ご紹介したSPA以外にもSIA等多くの機能が御座います。また「Cisco Secure Access」や「Cisco Umbrella」は、クラウドセキュリティ製品となるため、日々機能拡張が行われています。
そのため、今回ご紹介した以外の機能も複数ございます。つきましては、引き続き「Cisco Secure Access」のアップデート状況を確認し、昨今企業が抱える課題解決に役立つものを今後も検証し、ご紹介できればと思います。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
