大学の研究室ネットワークをCloudflare Zero Trustで武装した話
こんにちは！
博士前期課程にて情報工学を専攻しているかぼすと申します.
今回はCloudflare Zero Trustを利用して研究室内に配置されている計算機サーバへのSSH接続のセキュリティ強化を行ったので備忘録的に記事を書いていこうと思います.
背景
私が所属している研究室では画像や音声・音楽, 通信などを主な研究分野として扱っているため, 実験の際には高い計算能力を持つ実行環境が必要であり, 研究室内に約10基ほどの計算機サーバが配置されていました. しかしながら各計算機サーバにはip, user名, passwordのみ知っていればSSHで侵入できてしまう状態であり, 計算機サーバにバックドア等が仕掛けられていたりと何かの拍子で認証情報が漏洩してしまった場合, 組織に所属していない人間でも誰でも侵入できてしまうような状態でした.
これをどうにかしたいと考えた私は, 担当教員にCloudflare Zero Trust導入の打診をし, 承諾を得られたので導入に至りました.
Cloudflare Zero Trustとは？
Cloudflare Zero TrustとはCloudflareから提供されているセキュリティサービスです.
従来の境界型セキュリティをやめ, 対象に対しての通信全てに検証を施すというまさにZero Trustなセキュリティサービスとなっています.
天下のCloudflare様なので, ユーザ数が50名以下のサービス・組織であれば基本的に無料で利用できます.
Cloudflare Zero Trustでは主にAccessとTunnelを組み合わせてセキュリティの実装を行います. この内, 接続時に接続元に適応するルールの設定・検証を担うのがAccess, 検証通過後に接続対象に対して通信を行う通り道的な役割を担うのがTunnelとなっています.
Cloudflare Access
Cloudflare AccessとはCloudflare Zero Trustに含まれるコンポーネントの一つで, 指定のパブリックホストに接続する際に適用するルールの設定・検証を担うサービスです.
Cloudflare AccessではApplication単位で接続ルール等の設定をすることが可能で, 最大5つまでのパブリックホストを含むことができます.
作成したポリシーやログイン方法を設定することで接続時に検証する要素やログイン方法等をアプリケーション単位でまとめて設定することができます.
Cloudflare Tunnel
Cloudflare TunnelとはCloudflare Zero Trustに含まれるコンポーネントの一つで, サーバー内からCloudflare上のネットワークへアウトバンド接続を行うことで, ファイアウォールを開けずに社内リソースをインターネットへ公開・またはプライベート IP として拠点間接続できるリバーストンネルです.
HTTP/S, SSH, RDP, gRPC, TCP/UDP までプロトコルを選ばず扱うことができます.
この図を基にどのようなフローで接続を行っているのか説明します.
- ブラウザやターミナル等から
example.comへの接続を試みる - 最初にCloudflareのエッジサーバーに接続される
- ここでconfigを基にhostnameに対してTunnelがマッピングされる
- 加えてこのタイミングで設定されたポリシーを基に接続を試みるユーザがアクセスする権限を持つかどうかの検証を行う
- ポリシーを通過した場合, エッジサーバはTunnelに対してリクエストの転送を行う
- HTTP/HTTPS -> Tunnelへリバースプロキシ
- TCP/UDP -> WARP/Tunnelへ多重化QUICストリーム
- WebSocket/gRPC -> ハンドシェイク完了後パススルー
- この時4本のアウトバンド接続のうちの一つに接続される
- これによってどれかの接続が切断された場合でも自動でフェイルオーバーされる
- Tunnel(cloudflared)から
config.ymlのingressルールに従ってオリジンサーバーにリクエストが転送される
ここまで長々と説明してきましたが, 単刀直入に言うとTunnelはCloudflareネットワークとオリジンサーバーを接続する通信路のような役割を担っています.
これによりファイアウォールのポートを開く必要もなくなります.
研究室におけるCloudflare Zero Trustの運用
では実際に研究室内でどのようにCloudflare Zero Trustを運用しているのか解説します.
現状のアーキテクチャ
現状, 研究室サーバーへのアクセス制御は上記のような構成になっています. (秒で作ったので汚いとか言ったら抹消します)
各サーバーごとにTunnelを設置し, それらをApplicationに紐づけることでアクセス制御を行っています.
まずユーザーは研究室サーバーへ向けてSSH接続を試みます.(厳密には先に記したようにEdgeサーバーを通してTunnelに接続される)
するとCloudflare Accessにてポリシーの検証が入り, GitHub OAuthを利用して研究室のGitHub Organizationに所属しているかどうかチェックします.
万が一研究室のOrganizationに所属していないユーザーがアクセスを試みていた場合はこの時点で弾かれます.
研究室のOrganizationに所属しているユーザーだった場合, サーバーに対応するTunnelを介してユーザーは研究室サーバーと接続されます.
導入してみてよかったこと
1. セキュリティの強化ができた
Cloudflare Zero Trustを導入したことで, セキュリティプロバイダによる認証を導入しサーバーのポートも閉じることができました. もともとバックドアを仕掛けられたら終わりだったようなサーバーのセキュリティを改善することができたわけです.
まあGitHub上の何らかの脆弱性(Organizationに任意に侵入できる, ユーザーの乗っ取り etc)を突かれたら終いですが, 逆に言えばあのGitHub様が破られない限りは侵入ができないわけです. ポートも閉じてますしね.
2. 接続までのセットアップが楽になった
Zero Trustの導入によりGitHub OAuthによる認証ができるようになりました.
これにより研究室メンバーはGitHub Organizationに参加し, ローカルにcloudflaredをインストールし, ~/.ssh/configに設定をコピペするだけで接続できるようになり, SSH接続をするまでのセットアップを簡素化できました.
ssh-keyを生成して...計算機サーバーのauthorized_keyに登録して...みたいなことをしなくて済むようになりました.
3. ログイン状況がログで監視できる
Cloudflare Accessでのログイン試行はすべてCloudflareのWeb UI上でログとして確認することができます.
これにより誰がいつ, どのサーバーに対してログインを試みたのか, そのログインは成功したのか否かを監視することができます.
4. 安い
とにかく安い！！
かかった費用はドメイン費のみ！！年間たったの$7です！！
うーん...な点
ローカルネットワークがあった方が絶対良い
現状の研究室ネットワークでは各計算機サーバーに対してTunnelを設置し, いくつかのApplicationによりログイン管理を行っています.
しかし各Applicationにはパブリックホストを5つまでしか登録することができず, Tunnelの数が増えれば相対的にApplicationの数も増えてしまい, 管理がしんどくなってきます.
これを改善するにはゲートサーバーを利用して多段SSHによる接続を行う方法がありますが, これはローカルネットワークが構築されていない場合実現できません.
よって多数の接続先が存在するような場合においてはあらかじめローカルネットワークを構築しておき, 上記のような方法で実装するのをお勧めします.
(いずれ当研究室においても実装する予定)
ちなみにこの方法をとると, 各サーバーにcloudflaredをインストールしなくてよくなります.
ユーザー側にもcloudflaredを入れないといけないのがだるい
普段から技術に触れてる人ならたかだかアプリケーション1つインストールすることぐらい何も気にしないと思いますが, そうでない人からすればサーバーに接続するだけで何かをインストールしなきゃいけないってだけで結構ダルいと思います.
実際, 研究室にZero Trustを導入してからDocsを整備したにもかかわらず, 多くのメンバーがZero Trustに対応するまで時間がかかりました.
Cloudflareによるアクセス制御を行う上でどうしても必要なのは承知の上ですが, やはりうーん...と感じる点ではありました.
まとめ
以上研究室サーバーをCloudflare Zero Trustで武装してみた話でした.
研究内容の漏洩ほど悲しいことは無いですし, Zero Trustの設定も非常に簡単なので, この記事を通じてCloudflareによる研究室ネットワークのセキュア化が広まればいいなと思っています.
Discussion