開発環境のアクセス制限を柔軟かつセキュアにしてくれたCloudflare Access

ツール導入前の課題

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

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

どのような状態を目指していたか

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

• AWS ALBのOpenID Connect認証

導入にかかる手間が少なく、既存設定と干渉しないことです。

AWS ALBの既存設定をほとんど変更せずに導入できたことです。

改善したかった課題はどれくらい解決されたか

当社のセキュリティとアクセス管理を大きく向上させました。

どのような成果が得られたか

初期の設定や運用にはいくつかの課題がありましたが、それらを解決することで、より柔軟かつ安全な開発環境を実現することができました。

• 苦労した点1: AWS S3の静的ウェブホスティング機能との共存

私達の開発環境では一部のサービスがAWS S3の静的ウェブホスティング機能を使用しておりHTTPでのアクセスが必要となりました。しかし、CloudflareでのSSL証明書管理はFull(Strict)モードが必要となり、HTTPS通信が必須となります。 この問題はConfiguration Rulesを使用して特定ホストへのアクセスだけSSL/TLS設定をFlexibleに変更するという設定を行うことで回避しました。

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

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

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

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

弊社のような小規模開発チームであれば無料プランから利用することができるため、非常におすすめなツールです。