ゼロトラストセキュリティを目指す世界の中で、IP制限がかかっているレガシーなサイトにアクセスする必要があるときの方針

azure-ad-application-proxy-uml.png

zerotrust_with_ip_restrictions.md

概念整理タイム

ゼロトラストセキュリティとは

元来組織におけるセキュリティは、ネットワーク主体のDMZでネットワークを「UnTrust領域」と「Trust領域」で分割する手法でした。 オンプレミスなどが主流の世界の場合、これが成り立っていました。

しかし、高品質なシステムを安価に使用できるSaaSにで構成されるというのが当たり前になりました。 つまり、Trust領域にあったシステムがUnTrust領域に移行することになりました。

よって、Trust領域に攻撃者がいると考え、それに対してどのように対処するかがゼロトラストセキュリティです。

具体的には、完全な認証、承認、暗号化、その他属性などの情報をもとにエンドポイントがTrust領域にアクセスできるかどうかを判断します。

ゼロトラストとIP制限

従来行われてきたIP制限は特定の場所からのアクセスをもとにアクセスに制限をかけるという方法、つまり「UnTrust領域」と「Trust領域」で分割する手法です。

ゼロトラストセキュリティを目指す場合、このIP制限にギャップがあることがわかります。

現実問題に突き合わせる

現実問題、IP制限が残ってしまっているという状況をどうしても変えられないとことがあります。 その際には、大きく以下の2つの手段が考えられます。

• プロキシ
• SSL-VPN

前提条件

• インフラ面
  • MS365 E3/E5を導入している
  • Azureの資産を使用できる
  • AWSの資産を使用できる
  • 物理のVPN機器を使用できる
• 設計面
  • ゼロトラストの世界になるべく近づけたい
  • あとあとゼロトラストセキュリティの足かせにならないようしたい
• 具体的な要望・ユース
  • TCP 80/443でのアクセスのみ
  • 常にIP制限があるWebサイトにアクセスするわけではない
  • 組織からのアクセスであることを保証したい
  • 最低限Windows 10/macOSの端末からアクセスできること
  • イニシャルコストおよびメンテナンスコストが低いこと

「プロキシ」パターンソリューション案

Azure AD Application Proxy

IP制限があるサイトにアクセスする場合、以下のような構成になります。

sequenceDiagram
  participant ブラウザ
  participant AAD as Azure AD
  participant AP as Azure AD Application Proxy
  participant AC as Windows Server with Azure AD Application Connector
  participant 対象サイト

  autonumber
  ブラウザ ->>+ AAD: 認証要求
  Activate ブラウザ
  AAD ->> ブラウザ: 認証結果を返す
  ブラウザ ->> AAD: アクセス要求
  AAD ->> AAD: 認証の確認
  AAD ->> AAD: 認可
  AAD ->>- AP: リダイレクト
  Activate AP
  AP ->>+ AC: アクセス要求をプロキシ
  AC ->>+ 対象サイト: GIPを固定して対象サイトにアクセス
  対象サイト ->> 対象サイト: GIPの確認
  対象サイト ->>- AC: レスポンス
  AC ->>- AP: レスポンスをプロキシ
  AP ->> ブラウザ: レスポンス
  Deactivate AP
  Deactivate ブラウザ

Loading

Azure AD Application Proxy - Pros

• エンドユーザーはAzure ADエンタープライズアプリケーションと同じように使える
  • Azure ADの認証が通過している状態である
  • アプリケーションのアサインによって権限を絞れる
• エンドユーザーの端末側に追加でなにかアプリケーションまたはプロキシ設定を入れる必要がない

Azure AD Application Proxy - Cons

• プロキシなのでアクセスが重くなる可能性がある
• Windows Serverを稼働させるコストがかかる
  • 静的IP固定は350円/月
• Windows Serverをメンテナンスする必要がある

「SSL-VPN」パターンソリューション案

AWS Client VPN

https://dev.classmethod.jp/articles/aws-client-vpn-with-static-ip/ より

AWS Client VPN - Pros

• すぐに作成できる
• 「プロキシ」と異なりアクセスが遅くならない可能性が高い
• 各種VPNサービスと異なりスケールしやすい
• 認証はActive Direcotryと証明書認証、SAML 2.0をサポート
  • SAML以外はレガシーなので、新規構築の場合は避けたほうが無難

AWS Client VPN - Cons

• 証明書の配布方法を考える必要がある
  • 自動ならIntuneとJamfが必要
  • 手動なら全端末に管理者でインストールする
• NATゲートウェイとClient VPNのコストが結構かかる
  • $152.7/月 + Elastic IP: $3.6 + ネットワーク転送量: $0.062/GB

Cato Client

クラウド型のVPNクライアントです。GIPを固定するためにCato SocketなどでGIPを所有する拠点に繋ぐ必要があります

https://www.macnica.net/cato/ より

Cato Client - Pros

• コストが低い
  • $4/user/月
• 認証にIdPが使用できる
• CloudなのでVPNに関してはフルマネージド

Cato Client - Cons

• ユーザー管理にLDAPが必要
• 端末がSleepになるとCato Clientが起因してネットワーク自体につながらないことがある
  • 明示的にCato Clientを起動および終了を繰り返せば治る
• 代理店経由のため、初期導入に時間がかかる可能性がある