開発環境にCloudflare Accessを導入した話

2024/12/12に公開

これは SMat Advent Calendar 2024 の12/12分の記事です。

株式会社エスマットでエンジニアをしている potix2です。
私たちの開発環境はこれまでIPアドレスによるアクセス制限を採用していましたが、よりセキュアかつ柔軟なアクセス管理を実現するため、Cloudflare Accessの導入を決定しました。この記事では、その移行プロセス、遭遇した課題、および解決策について詳しく説明します。

なぜCloudflare Accessを導入したのか

従来のIPアドレスに基づくアクセス制限は、その単純さから選ばれていましたが、最近のオフィス移転に伴い、固定IPアドレスの利用が不可能になりました。この変化は、セキュリティとアクセシビリティのバランスを再考させる重要な要因となりました。特に以下のような課題がありました。

  • 固定IPアドレスの喪失:オフィス移転により、以前に利用していた固定IPアドレスが使えなくなり、IPベースのアクセスリストを維持することが不可能になりました。
  • 動的なIPアドレスの問題:リモートワーカーのIPアドレスは頻繁に変わるため、IPベースのアクセスリストを常に更新する必要がありました。この作業はSREチームが担当しており、変更箇所が多いため手間がかかっていました。

これらの課題に対応するため、Cloudflare Accessを導入しました。これにより、ユーザーの身元を検証し、セキュアなアクセスを保証するZero Trustセキュリティモデルを採用できるようになりました。また、Cloudflareのグローバルネットワークを利用することで、パフォーマンスの向上とダウンタイムの低減を図ることができました。

元々の構成

名前解決のみをCloudflareに委譲している状態で、AWSのALBに設定するセキュリティグループによってアクセス制限を行っていました。

Cloudflare Access導入後の構成

HTTPリクエストをCloudflareのネットワークにルーティングし、Cloudflare Accessの認証を経て、AWSのALBにリクエストを転送するように変更しました。

Cloudflare Accessの導入

前提条件

以下の条件を満たすことが、Cloudflare Accessの導入に必要です。

  • DNS Proxyの有効化
  • SSL/TLS証明書の管理をCloudflareに委任

DNS Proxyの有効化

DNS Proxyを有効にすることで、CloudflareのAnycastアドレスが返されるようになり、トラフィックがCloudflareのネットワークを経由するように変更されます。

この変更によってALBは、オリジンサーバーとして機能するようになるためALBのアクセス元はすべてCloudflareになります。そのためALBの設定を変更し、Cloudflareからのアクセスを許可する必要があります。

SSL/TLS証明書の管理をCloudflareに委任

クライアントはCloudflareのAnycastアドレスに対してHTTPSリクエストを送信します。Cloudflareは、オリジンサーバーとの間でTLS接続を確立し、リクエストを転送します。このため、Cloudflareのネットワークとオリジンサーバーの間でTLS接続を確立する必要があります。そのためには、Cloudflareのネットワークにおいてオリジンサーバーの証明書を管理する必要があります。

Full Strict SSLモードの必要性

CloudflareでのSSL証明書管理は、安全な通信を保証する上で重要です。特に、CloudflareとALB間の通信を保護するためにはFull(Strict)モードが必要となります。

参考: Encryption modes - Cloudflare SSL/TLS docs

しかし、私達の開発環境では一部のサービスがAWS S3の静的ウェブホスティング機能を使用しておりHTTPでのアクセスが必要となりました。この問題はConfiguration Rulesを使用して解決しました。

Configuration Rulesの活用

Configuration Rulesとは受信されたリクエストを特定のルールによって振り分けて、何らかの機能の設定の上書きや実行を行います。今回の場合は、HTTPでのアクセスを許可したいホストの場合に限ってSSL/TLS設定をFlexibleに変更するという設定を行いました。

サイドメニューからConfiguration Rulesをクリックします。

Create ruleのボタンをクリックし、Configuration Ruleの作成ページを開きます。

受信したリクエストを絞り組む条件を設定します。今回はルールの適用を特定ホストに制限したいのでホスト名を条件に設定しています。

SSL設定をFlexibleに上書きします。

苦労した点とその解決策

苦労した点1: 特定のホストへのIPアクセス制限

特定のホストだけをIPアドレスでアクセス制限したい場合、Cloudflareでグループを作成し、Bypassルールを設定しましたが、期待通りに機能しませんでした。ページ表示は可能でしたが、バックエンドへの通信時に認証画面へリダイレクトされてしまう問題が発生しました。この問題は、該当サービスのみDNS ProxyをオフにしてCloudflareを経由させないことで回避しました。

苦労した点2: curlなどのツールからのAPI呼び出し

curlなどのツールを使用してAPIを呼び出すと、認証画面にリダイレクトされる問題が発生しました。これを解決するために、サービストークンを発行し、リクエストヘッダに付与する方法を採用しました。Cloudflare Accessのルールを設定する際には、サービストークンを含んだアクセスを許可するルールを設定しました。このとき、ルールのアクションとしてServiceAuthを選択する必要があります。

結論

Cloudflare Accessの導入は、当社のセキュリティとアクセス管理を大きく向上させました。初期の設定や運用にはいくつかの課題がありましたが、それらを解決することで、より柔軟かつ安全な開発環境を実現することができました。

GitHubで編集を提案
株式会社エスマット

Discussion