「御社の会計ソフトと連携させたいので、うちのIDとパスワードを開発チームに教えてもらえますか」。ある製造業の経理担当者が、システム連携の打ち合わせでこう切り出した瞬間、開発会社側の担当者の表情がわずかに固まった。悪意があっての要望ではない。むしろ協力的に、早く連携を進めたいという善意からの申し出だった。しかし開発側は丁重にこう答えるしかない。「パスワードはお預かりできません」。発注者は戸惑う。連携するには認証情報が必要なはずなのに、なぜ渡してはいけないのか。逆の場面もある。開発会社が発注者に対して、外部サービスとの連携のためにパスワードの共有を求められ、強い抵抗を感じながらも仕方なく預かってしまうケースだ。どちらの場面にも共通しているのは、パスワードという「万能の鍵」をそのまま渡すことへの漠然とした不安であり、その不安の正体を言葉にできないまま、なんとなく気まずい空気だけが残ってしまうということである。
なぜこの戸惑いが起きてしまうのか
第一の理由は、パスワードを渡すという行為が、金庫の鍵をまるごと渡すのと同じ意味を持ってしまうからである。会計システムに連携先が必要なのは「入金データを読み取る」というただ一つの操作かもしれない。しかしIDとパスワードを渡してしまえば、相手はその会計ソフトでできることすべてを実行できる状態になる。請求書の発行も、取引先情報の変更も、退職金の計算も、本来渡すつもりのなかった権限まですべてが渡ってしまう。
第二の理由は、連携を止めたいと思ったときの手段がパスワード変更しかないことである。特定の連携先だけとの関係を解消したいのに、パスワードを変えると他のすべての連携やログインしているスタッフにも影響が及んでしまう。一つの糸を切りたいだけなのに、束ねられた糸をすべて切らざるを得ない状態に陥る。
第三の理由は、誰にどの権限を渡したのか、時間が経つほど管理できなくなることである。半年前に連携した会計ソフト、一年前に試験導入したまま忘れられていたツール、担当者が退職して引き継がれなかった連携。パスワードという形で渡された権限は、一覧化も棚卸しもされないまま静かに積み重なっていく。
放置するとどうなるか
多くの現場では、複数のサービスで同じパスワードを使い回している。ある一つの連携先からパスワードが漏れれば、そのパスワードを使っている他のすべてのシステムが同時に危険にさらされる。一つの穴が、想定していなかった場所にまで広がっていくのである。さらに厄介なのは、担当者の異動や退職である。かつて連携設定を行った担当者がいなくなったあとも、その人が発行に関わったパスワードや権限はシステムの奥に残り続け、誰も気づかないまま有効であり続けることが少なくない。そしてこうした状態は、セキュリティ監査や取引先からの信頼性確認の場面で必ず表面化する。「誰が、いつ、どの権限を、なぜ持っているのか説明してください」という問いに答えられないことは、それ自体が経営上のリスクとして指摘される。パスワードを渡すという一見手軽なやり方は、後になるほど重い代償を払う選択になっていく。
OAuth認証とは何か、何を解決するのか
自宅の合鍵をそのまま渡す代わりに、特定の部屋にしか入れず、期限が来れば自動的に無効になるカードキーを発行する。OAuth認証とは、そうした考え方をシステムの世界に持ち込んだ仕組みである。「Googleでログイン」というボタンを押したとき、私たちはGoogleのパスワードをそのサービスに教えているわけではない。Google側で本人確認をしたうえで、そのサービスに対して「この人の名前とメールアドレスだけを渡してよい」という限定的な許可証を発行しているのである。
パスワードを渡さずに「できること」だけを渡す
OAuth認証の核心は、認証情報そのものを渡さず、権限だけを切り出して渡すという発想にある。会計ソフトとの連携であれば「入金データを読み取る」という一点だけを許可すればよい。パスワードという万能の鍵ではなく、その一室にしか入れない専用の鍵を新たに作り、それだけを相手に渡す。渡す側は自分がすべてを明け渡したという不安から解放され、受け取る側も必要以上の責任を背負わずに済む。
渡した権限をいつでも取り消せる
カードキーはいつでも無効化できる。OAuth認証で発行された権限も同様で、特定の連携だけを選んで取り消すことができる。パスワードを変える必要はなく、他の連携にも一切影響を与えない。ある取引先との契約が終わったとき、その連携の許可証だけを静かに無効化すればよい。糸を一本ずつ扱えるということが、この仕組みの実務上の大きな価値である。
誰にどの権限を渡しているか一覧で管理できる
OAuth認証に対応したサービスの多くは、どの外部サービスにどの権限を渡しているかを一覧表示する管理画面を備えている。かつて連携した名前も覚えていないようなサービスまで含めて、渡した権限を可視化し、棚卸しできる。誰が、いつ、何のためにその権限を許可したのかが記録として残ることは、監査の場面でも大きな安心材料になる。
導入時の注意点
すべての外部連携をOAuth対応に統一する必要はない。連携したい相手サービスがそもそもOAuth認証に対応していないケースも珍しくなく、その場合は別の安全な方法を検討する必要がある。また、OAuth認証に対応していれば安全というわけでもない。権限の範囲を必要最小限に絞ることが重要であり、「読み取りだけでよいはずなのに、書き込みまで含めた広い権限を許可してしまっている」という状態では、せっかくの仕組みが十分に機能しない。発注先には、どの権限をどの範囲で要求しているのか、その連携に本当にその権限が必要なのかを具体的に確認することをお勧めしたい。
現実的な進め方
すべての連携を一斉にOAuth対応へ切り替える必要はない。まずは重要度の高い連携、たとえば会計や人事といった機密性の高い情報を扱うシステムから優先的に見直し、パスワードを直接渡す方式からOAuth認証への移行を進めるのが現実的である。並行して、現在どのような連携が存在し、それぞれにどのような権限が渡っているのかを洗い出す棚卸し作業を行えば、次にどこに手をつけるべきかが自然と見えてくる。焦って全体を作り替えるのではなく、リスクの大きいところから着実に、一歩ずつ壁を低くしていくことが、結局は最も早い道になる。
壁を越えて働く人たちへ
連携を進めたいという思いと、大切な情報を守りたいという思いは、本来対立するものではない。パスワードを渡すか渡さないかという二択で立ち止まってしまう必要はなく、必要な権限だけを、必要な相手に、必要な期間だけ渡すという選択肢が確かに存在する。オルアナは、システムとシステムの間に立ちはだかる見えない壁を越えようとする人たちのそばに立ちたいと考えている。連携の一歩を踏み出す勇気と、情報を守る責任感は、どちらも同じ人の中に共存してよいものだ。その両方を支える仕組みを選び取ることこそが、壁を越えて働くということなのだと思う。