開発環境のアクセス制限の方法2点の比較
これはなに？
システムを開発する上で、開発環境(関係者だけに見せたい環境)を作るかと思いますが、その上でアクセス制限についての検討は避けられないトピックだと思います。
このポストではアクセス制限の選択肢として以下の2つの運用面での長所と短所を検討します。
- Basic認証
- IP制限
前提
そもそもこの2つを選んで検討した理由などとして、あまり難しいことをせずに極力コンパクトに実現したいというのがあります。
基本的にはアプリケーションに手を加えずにどうやってアプリケーションへのアクセスを制限するか、という目線で考えています。
それぞれの方法についての検討
Basic認証
Basic認証はRFC7617で定義されている認証方式です。
簡単な仕組みの解説としては、ID/PWをbase64エンコードしてHTTPリクエストヘッダに載せて送りつけることでサーバ側に正規のユーザであることを示す方式です。
Basic認証はユーザのクレデンシャルを平文で送る仕組みのため第三者が経路上でリクエストを見た際にはそのままID/PWを読み取ることが可能です。そのため、TLSなどと併用して通信経路を安全に保つことが必要です (これは一般的なログインと一緒ですが...)
実現方法の参考: https://developer.mozilla.org/ja/docs/Web/HTTP/Authentication
長所短所についての検討についてはこちらのリンクも参考になるかと思います。
Basic認証の長所
導入が容易
Basic認証は実装が簡単でHTTPサーバのレイヤーでもアプリケーションのレイヤーでも機能が提供されていたり、プラグインのような形で既存の実装をそのまま導入可能なケースが多いです。
Basic認証の短所
ログアウト機能がない
Basic認証自体はステートレスなため強制ログアウトで背後にあるリソースへのアクセスを禁止する、などはできません。とはいえこの点は今回のコンテキストにはあまり関係ないでしょう
Basic認証の運用上の注意点
Basic認証自体に由来する問題ではないが、一般的な実装や運用を見て割と問題になりそうなところなどについて検討してみました。
OAuth2/OIDCで使われるBearer tokenと衝突する
Basic認証はAuthorizationヘッダを使う[1]が、これはOAuth2で定義されているBearer Tokenをリクエストヘッダ経由で送る場合に使われるヘッダでもあります。なのでこの2つを同居させることができるのはBearer TokenをAuthorizationヘッダ以外で送るケースのみです[2]
ID/PWを知っていればどこからでもログイン可能(棚卸ししよう)
これは、Basic認証に限らず大雑把に言えば「ユーザのデータを個別に持つログイン」機能全般がそうなので、これを避けたければ開発環境のアクセス制限に個別実装されたログイン的な機能を使うのをやめましょう、という話になります。
具体的にどういうケースを想像しているかと言うと、何らかの事情からNW的な制限を設けるのが難しいようなケース(例えばSaaSでインフラレイヤーがコントローラブルでないなど)で、人の入れ替わりが激しい組織でBasic認証を使っていたとすると、人が組織から抜けたタイミングでその人がログインできないように設定ファイルからその人の行を消さないといけないですが、あまりにも入れ替わりが激しすぎてうっかり漏れが発生しました、みたいなケースです。
一般的にはBasic認証は個々のシステム上で(しかも実現方法自体はそのシステムの構成によってまちまち)実現するため、かなり雑な言い方をするとBasic認証を採用しているシステムの個数分漏れが発生するリスクは高まります、という話です。(裏側で統一管理されているユーザのデータベースなどがあればここのリスクはあまりなさそう)
IP制限
イメージとしては、AWSのsecurity groupやGCPのfirewall ruleのようにネットワークレベルでのアクセス制御をイメージしてください
IP制限の長所
ユーザが組織から抜けた瞬間にアクセスを弾ける
開発環境へのアクセスを社内からのみ、とかにすると退職したらたとえID/PWを知ってようがアプリケーションの攻撃方法を知っていようがアクセスできなくなります。
一般的な会社は多分社員が退職した翌月とかでも引き続きその会社のNWに入れたりしないと思いますが、もう少しそっちの方向で考えると、来客などのために提供している誰でもつなげるwifiアクセスポイントなどがあってそこからインターネットに出るIPアドレスが一緒、とかはたまにありそうな落とし穴だなと思いました(その場合この方法は使えない)
IP制限の短所
アクセス制限の粒度が粗い
正確には細かい粒度でのアクセス制限は管理コストが高くなる、という言い方が正確ですが例えばユーザごとにIPアドレスでのアクセス制限を行うのはまあまあ面倒くさいというのは同意が得られると思います。
そのため、例えばオフィス、フロア、部屋などある程度の単位でざっくりした制限を行うことになると思いますが、これはユーザごとで制御ができないのでできれば別の仕組み(例えばBasic認証など)と組み合わせて別軸の制御を入れるとよいのではないでしょうか
パブリックな環境からのアクセスはできない
これは当然ですが、公共施設などにある誰でも接続可能なNWからのアクセスを許可しては意味がありません
その他: 物理的にクライアントと同じNWにあるものを使うとだいぶ安全になりそう
非常にシンプルな話ですが、オフィス内にあるサーバ上で動くサービスに対して、同じオフィスからしかアクセスできないようにした場合パブリックな環境で配信しているサービスに比べて外部の人間が不正にアクセスする難度は高いです(たとえアプリケーション自体にはなんのアクセス制御もかかっていなかったとしても)
まとめ
それぞれ長所も短所もあるので組み合わせるとお手軽な割にまあまあ安全になって良さそうですね、と思いました。
おまけ: GCPならIAPを使うと良さそう
会社でGoogle Workspace(GSuite)でアカウント管理をしていて、なおかつGCP上でGAEやHTTPSを受けるロードバランサを使ったシステムを構成する場合、IAP(Identitiy Aware Proxy)を使うと、会社の組織のアカウント管理に連動して開発環境にアクセス可能な人を絞れる + 特にシステム側での実装も必要なくてコスパの良い方法なのではないかと思います。
参考: https://cloud.google.com/iap/docs/app-engine-quickstart
Discussion