読者です 読者をやめる 読者になる 読者になる

ポエム:社内ツールのセキュリティについて

ポエム

(注:このエントリーはポエムです)

社内ツールのセキュリティを高めたいという需要は常にある。しかしセキュリティと利便性は相反することが多い。とはいえセキュリティを高めようとして利便性が損なわれてしまったら、社内の理解は得にくいと思う。

ただ使いにくいだけならまだしも、社内ツールで緊急対応などを行う場合もある。利便性が損なわれたがために緊急対応が遅れてしまうなどのことが起これば、それは会社にとってもユーザーにとってもデメリットが大きいし、避けなければならない事案だと思う。

一般的に社内ツールのセキュリティをどう担保すればよいのか、考えてみた。

イントラネット

イントラネットとは企業内ネットワークのことで、雑にやるなら社内LAN内にベニヤ板サーバーみたいなのを置いて、そこでサービスを提供すればよい。

利点

  • オフィス自体のセキュリティが万全であるならば(ここが心配ならばそもそも社内ツールのセキュリティを心配している場合ではないので今回は気にしない)、外部から侵入されることなどの心配をすることはない
  • 社内のネットワークに所属していれば、(社内のネットワークに所属している全員が信頼できるという前提つきではあるが)認証やセキュリティは雑でも大丈夫
  • 社内ツール自体にユーザーという概念がないなら、ユーザー管理をしなくてよい

欠点

  • 同一ネットワーク内に所属する方法がWi-Fiのパスワードのみだったりすると、そのパスワードが漏れた時点で崩壊する
  • 外部からつなげないので物理的に特定の場所に行く必要がある
    • VPNを使えば外からつなぐことはできるが、VPNを用意すればVPNのパスワードが漏れた時点で崩壊する
    • VPNの設定やそのユーザー管理などは基本的に煩雑で管理者のコストが高い
    • VPN自体の同時接続数を上げるには高い機器が必要なのでそもそも大人数が同時に繋ぐことが難しい
  • 特別なオフィスでは無い限り、停電などのリスクがあるのでサーバーを立てるのはそもそも向いていない

IPアドレスによる制限

例えばオフィスのネットワークが外に出るときのIPが決まっているなら、そのIPを使って認証すれば良い。

利点

  • nginxやiptablesなどを使って簡単に制御できるので設定が容易
  • サーバー自体は外部にあってもセキュリティをある程度担保できる可能性がある
  • 社内ツール自体にユーザーという概念がないなら、ユーザー管理をしなくてよい

欠点

  • 雑なプロバイダーだと固定IPをもらえない
  • 同一ネットワーク内に所属する方法がWi-Fiのパスワードのみだったりすると、そのパスワードが漏れた時点で崩壊する
  • 外部からつなげないので物理的に特定の場所に行く必要がある
    • VPNを使えば外からつなぐことはできるが、VPNを用意すればVPNのパスワードが漏れた時点で崩壊する
    • VPNの設定やそのユーザー管理などは基本的に煩雑で管理者のコストが高い
    • VPN自体の同時接続数を上げるには高い機器が必要なのでそもそも大人数が同時に繋ぐことが難しい

Google認証などの統一的な認証APIを使用する

利点

  • Google Appsを使えば特定ドメインのメールアドレスでGoogle認証をできるので、ドメインで許可ができればGoogleのアカウントの管理がちゃんとしていればセキュリティはある程度担保できる
  • Googleの2段階認証を使っていればパスワードが漏れただけで侵入されることはない上に、Googleが勝手にアカウントのログイン履歴を監視してくれるので怪しい動きがあれば教えてもらえる可能性がある
  • Googleアカウントのパスワードは絶対に流出させてはいけないということは常識なので教えるまでもない
    • これが分からない人間は雇うべきではない(分かっていない人間は世の中に一定数いる)
  • オフィスのネットワークに所属する必要が無いので、社外でも普通に仕事ができるようになる
    • 緊急対応やリモート勤務などが容易になる

欠点

  • 社内ツールすべてで脆弱性無く、Google認証を実装するのは現実的ではない
    • これを解決できる方法は後述
  • Googleのアカウントを管理する必要がある
    • ほとんどの会社がすでに管理していると思う
  • Googleの管理画面からTokenを発行するなど、設定が少し煩雑
  • Googleの場合、某国の某盾に遮られる

Google認証を簡単に導入する方法

社内ツールは歴史的経緯もあり、どういう言語で実装されているかも分からないし、そもそもソースコードに手を入れる必要があればいくら時間があっても足りないだろう。ソースコードをいじることなくGoogle認証をいれたい。

そんなときはGoogle認証が通ったときだけ社内ツールへプロクシしてくれるプロクシサーバーを間に立てればよい。社内ツール側は特に変更する必要が無いし、一番外側の認証するプロクシサーバーのセキュリティに気をつけていれば社内ツール自体のセキュリティリスクに悩まされることはないはずだ。そしてそれを行えるツールはいくつかある。

私が個人的に最近おすすめしているのはBitly社の bitly/oauth2_proxy だ。使い方も導入もREADME通りにやればできるし、単純なプロクシサーバーとして動くのでほとんどの社内ツールで簡単に導入できるはずだ。またGo言語で実装されているので、もし問題を見つけたら実装を読めばいいと自分が思っているのもある。Google認証以外もあるので各社の事情にも合わせやすいと思う。

まとめ

上の3つはすべてやっているのだけど、結局Google認証が一番安心できるというのが今のところの感想。ただし外部のネットワークからアクセスできるようにする場合、社内ツールは機密情報を扱うことが多いのでHTTPS化もするべき。

ちなみに今回のリストにBASIC認証は外した。理由は言わずもがな。