Serverlessで構築する社内ID基盤
森岡周平氏（以下、森岡）：それでは、「Serverlessで構築する社内ID基盤」というテーマで、株式会社Speee開発基盤ユニットの森岡から発表させていただきます。今日は、Google Cloud Platformを利用してServerlessでID基盤を構築したことについてお話をさせていただきます。
今回ID基盤を構築してIDaaSにAzureADを利用したんですが、「どうしてAzureADを利用したのか？」という話だったり、AzureADの細かい話については勉強会のテーマとそぐわないのでお話をしません。
また、GCPでServerless開発をする上でのTipsなどについても時間の関係でカットさせていただきます。もし興味のある方がいましたら、あとで質問していただけたら回答しますのでお聞きください。
今日の発表ですが、こんな感じのアジェンダで説明させていただきます。
まず自己紹介です。
あらためまして、株式会社Speeeの開発基盤ユニットで仕事をしている森岡です。最近の業務はこんな感じのものがありまして、本日お話しするID基盤を構築するきっかけとなったIDaaSの導入を、現在は業務として進めております。
IDaaS導入の背景
このIDaaSを導入しようと思った背景についてお話させていただきます。
以前「Speee Cafe Meetup」という勉強会でお話しさせていただいたのですが、僕がSpeeeの開発基盤ユニットで最初にやった仕事は、全社で統一する監視ツールの選定と導入でした。
これを進めた結果、監視ツールが全部統一されたので、監視に対するナレッジが社内で共有されていったということがあって、すごく便利なんですけれども。一方で問題点として、開発基盤ユニットが管理しなきゃいけないツールがどんどん増えていったんです。
こんな感じで。
開発基盤ユニットは当時僕1人で、AWS、SendGrid、Datadog、なんちゃらかんちゃら……、みたいなやつを全部僕1人で管理していて、「とてもじゃないけど手が回らないぞ」という感じになって、IDaaSの導入を考え始めました。
急にIDaaSって話をしちゃったのですが、IDaaSって聞いたことのある方、この中にどれぐらいいらっしゃいますか？
（会場挙手）
あ、けっこういました。ありがとうございます。
IDaaSとは何か？
基本的に、IDaaSって言われても、たぶんセキュリティとか情シスの方以外はあんまり馴染みのない言葉かなと思うんですが、たぶんみなさんも使ったことはあると思うんですよね。
IDaaSって何かというと、Identity as a Serviceの略称でして、従業員のID管理だったり、アクセス制御、またSingle Sign Onを提供するクラウドサービスになっています。OneLoginとかOkta、AzureAD、PingFederateなどが代表的なものですね。
IDaaSを導入する前って、たぶん各サービスごとにアカウントを作成してID・パスワードを管理していると思うんですけれども、IDaaSを導入すると、1つのID・パスワードですべてのアカウントにアクセスができるようになります。
このような感じでアカウントの作成とか削除のコストが非常に下がるので、運用コストが下がるだけでなく、このレイヤーでパスワードポリシーを厳しくしたり、MFAを強制することによって、セキュリティの強化を図ることができるようになります。
IDaaS導入前のうちの会社の状況ですが、各部署それぞれがいろんなツールを持っていました。それぞれでID管理をしているような状態になっていました。IDaaSを導入すると、こんな感じでバラバラに管理されているものが1つものに統合されるようになります。こうすることによって、各部署でのID管理の工数が下がるだけでなくて、退職者とか異動された人のアカウントの消し忘れとかも防ぐことができるようになります。
ID管理ってちゃんとやろうとするとけっこうコストがかかるんですけど、IDaaSを導入することによってそのコストを下げることができるようになります。管理工数の話をしたのですが、それ以外にも全社的なセキュリティの水準を担保できるようになったりします。
そのほかにもIDaaSにはいくつか機能がありまして、例えば社外からのアクセスだったら多要素認証を強制するだったり、誰がいつどのようなサービスにアクセスしたかという監査ログを残すだったり、万が一アカウントが流出してしまったとしても、そのアカウントを即時に止めることができて、被害が広がることを防ぐみたいなことができたりします。
システムの全体像
長々とIDaaSについて話しちゃったのですが、そろそろServerlessの話に戻ってきます。IDaaSを全社的に導入することになったので、それを実現するためのID基盤を作ることになりましたという話をしていきます。
最初に要件のことを話していくと、ものすごく長くなると思うんですね。社内のID基盤っていろんな背景があってものすごく面倒くさいので、そこから話すと眠くなっちゃうかなと思ったので、いったん全体像から出していきます。
作ったのがこんな感じです。「なんでBigQueryがいるの!?」みたいな感じでみんなびっくりだと思うんですけれども、こんな感じの構成にしました。
まずはBigQuery上で社員のマスタを作成して、そこからCloud FunctionsでAzureADにデータを突っ込むみたいな流れになっています。
本当はもっと細かい要素がたくさんあるんですけど、今回は単純にわかりやすくするためにこのように端折って図を作りました。後で細かくお話をしていきます。
さっきの構成図を見たら「なんであんな簡単なことをするのに、こんな変なことするの？」と気になると思うんですけれども、その理由についてこれから説明していきます。
システム要件
まずIDaaSにデータを投入したかったので社員マスタが欲しかったんですけど、人事の人が管理している社員マスタには、評価などのとても機密性が高い情報がたくさん含まれていて、気軽にエンジニアが開発に使えなかったんですね。気軽に開発がしたかったので、社員マスタからIDaaSに必要な情報だけ抽出したかったんです。けれどもそんなことができるようなシステムは社内になかったので、自分で作るしかありませんでした。
そもそも社員マスタ自体の運用が固まっていなかったことで、過去に事故が起こったこともあったんですね。どういう事故かというと、例えば昔いた人と同じ名前の人が入社したときに、同じメールアドレスを付与しちゃったみたいな。これはすぐ気づいてすぐ対応されたので大丈夫だったんですけれども、手運用しているとそういう障害が起きたりします。なのでそういう問題が起きないように、信頼できる社員マスタを作る必要がありました。
ということで、今回作るシステムの要件がこちらになります。
すごい機密情報を持っているので、社員マスタ自体に直接触れることができるエンジニアはごく少数にします。その上で社員マスタからIDaaSに必要なデータのみ整形・抽出できるようにします。IDaaSのシステムはこのデータをセキュアにアクセスできるようにして、そのデータをもとに自身の従業員のデータを更新するようにします。
このような運用をするにあたって、人事の方の作業を大きく変えてしまうと混乱が発生するので、人事の方は何も手を加えずにこのようなことができるようにしました。このIDaaSとは別文脈で、ほかのサービスでもこの社員マスタを使いたいみたいな要望があとで来たので、ここも対応できるようなシステムにする必要がありました。
システムの流れ
さっきの図をちょっとかっこよくすると、こんな感じの図になります。
この流れを簡単に説明していくと、人事の方がデータをクラウド人材管理サービスにどんどん入力していくんですけれども、その入力した情報を全社に反映してもいいよというタイミングになったときに、このApp Makerにアクセスして反映する手続きを取りにいきます。
そうすると、Cloud Functionsが各種社内サービスにアクセスしにいってデータを取得します。そしてそのデータに対してValidationを行います。
このValidationというのは、先ほどお話しした「同一メールアドレスが存在していないか？」であったり。あとは社員マスタって自動化に使われることを想定しないので、よくジョブタイトルに「社員」「_社員」とあったり、データがすごいごちゃごちゃしているので、こういうものがないかを確認していきます。Validationの結果と変更内容を人事の方に提示して、問題がなければSubmitボタンを押してもらいます。そうするとそのデータがCloud Storageにアップロードされます。
Cloud Storageにアップロードされると、Dataprepが起動して不要なデータのクレンジングとかデータの整形を行います。「不要なデータのクレンジング」と書いてあるんですけれども、弊社の人材管理サービスには社員番号0番にPepper君がいたりして、とてもIDaaSには使えないデータなので、そういうのをどんどん取り除いていきます。
そして、過去のデータをSnapshotとしてBigQuery側で保存して、新しいデータをいまの既存のテーブルにインポートします。そして社内サービスごとにデータを抽出して、このViewを作っていきます。
この生成されたViewに対して、それぞれ適切なサービスアカウントのアクセス権限を設定していきます。IDaaSのViewだったらそのIDaaSのGCPプロジェクトしかアクセスできないようにして、勤怠用のサービスだったら勤怠のGCPプロジェクトしかアクセスできないようにする、みたいなことを一つひとつやっていきます。
そしてその各サービスは、それぞれのViewをもとにデータを取得して処理をしていくみたいな流れにしています。
設計における考え方
設計する上ですごく注意した考え方なんですけれども、データの更新は必ずこの方向にすることにしていました。どうしてかというと、例えばこのIDaaSプロジェクトからBigQueryにデータが戻せるみたいになってくると、どういう経路でデータが更新されたのかが追えなくなっちゃうんですよね。なので必ず、データの更新はこの方向にだけやっていくというような考え方で設計をしていきました。
さっきのが理想像なんですけれども、現在はこんな感じになっています。IDaaSプロジェクトだけ存在する感じで、ほかのやつは4月以降に対応していく予定です。
システムの恩恵
このようなシステムを作ったことによってどういう恩恵が受けられたかというと、社内に散らばっている各種データを1つにまとめることができました。また、社内サービスに連携するためのデータは整形・Validation済みなので、受け取る側はそれをそのまま信じてサービスに反映できます。
また、社内サービスは必要最小限のデータのみ参照可能となっているので、社員マスタにアクセスしようと思ったら宣誓書とかを書かなきゃいけなかったりすると思うんですけれども、そういうことが不要になって、いろんなエンジニアが社内ツールの開発に参加できるようになります。
あと、大半の人事用のサービスには、誰がいつどこにいたのかといった履歴データは残っていないと思うんですけれども、人事用のSaaSのSnapshotがBigQueryに保持されているので、そういうことを過去にわたって分析ができるようになりました。
また、分析をBigQuery上でするようになるので、人事用のSaaSがただの入力装置になります。なのでその人事用SaaSが不必要になったときに、Dataprepだけちょちょっといじれば過去のデータと同じようなかたちになるので、簡単にリプレイスができるようになります。このような理由でBigQueryを採用しています。
IDaaSデータの反映
ここまでがほとんどメインですが、データをCloud Functionsを使ってIDaaSに反映していきます。
BigQueryが更新されたらフックが飛んで、Cloud Functionsが自動で起動します。その起動したCloud FunctionsがViewにデータを読み込みにいって、Microsoft Graph APIを使ってAuzureADのデータを更新します。AzureADとG Suiteは同期されているので、AzureAD上の従業員情報などはG Suiteにも同期されるようになっています。従業員は、AzureADにアクセスして、そこからAWSだったりSalesforce、DatadogだったりにSSOするようなかたちになっています。
このシステムを作るにあたって注意した点なんですけれども、BigQueryのViewを常に正としてIDaaSのデータを更新します。BigQueryのViewの内容をもうそのまま全部突っ込む。必ずBigQueryのデータをそのまま入れられるようにする感じです。
なんでこうしたのかというと、冪等性を担保したかったんです。Cloud Functionsなので何回も実行されてしまうみたいなことが、多分にあると思うんです。そのときに必ずBigQueryと同じかたちのデータにすることが決まっていたら冪等性が担保できるかなと思って、このようにしています。
万が一問題があったとして、ロールバックしなければいけないとなったときに、過去のデータを参照するようにすれば、すぐにロールバックができるようになっています。AzureAD自体にはロールバックみたいな機能がないので、こういうかたちでロールバックを実現しています。
あともう1つ、AzureAD上では必ず従業員を消さないようにしているのが1点の工夫ポイントです。なんでかというと、先ほどお話ししたメールアドレスの重複登録の対策です。
先ほどの社員マスタ作成時にも一応Validationでチェックはしているのですが、これはすごくセキュリティ的に問題があるものなので、AzureAD上でもチェックして必ずダブルチェックをするようにしています。
このAzureADなのですが、従業員数課金ではなくてライセンス数課金なので、いくらでも従業員を登録できます。なので退職者のデータも保持しておくことで、メールアドレスが重複しないように検査しています。
App Maker
ここはおまけなのですが、人事の人が触るアプリケーションの説明です。
これもServerlessでやっていて、Googleが提供してくれているApp Makerというものを使っています。
これはUI操作で簡単な静的サイトが作成できるようなものなんですけれども、「Speee.jpドメインのメールアドレスを持っているユーザーしか触れない」のように閲覧者の設定が細かくできるので、一定セキュアな静的サイトが作れたりします。
こういうものを使って、Cloud Functionsを実行して、データのDiffを見れるようにしています。何が更新されたのかを見て、問題なければ反映するみたいな手続きを取っています。
まとめ
まとめです。
IDaaSの基盤を作るにあたって、ほとんど既存の運用を変えずに、運用コストを増やさずむしろ削減して実現することができました。また、BigQueryを利用してセキュアでスケールする社員マスタが構築できました。常にバックアップが取られているので、人事系SaaSへの依存度が大きく減少しています。
また、IDaaS以外のツールもViewで切り出せば簡単に連携できるようになっているのと、BigQueryの料金はたまっているデータ量とクエリで操作する量に依存するので、社員ぐらいのデータじゃほとんどお金がかからないんですよね。ということで、BigQueryは無料枠で利用できています。
BigQueryを正としてIDaaSにデータを反映することによって、冪等性が担保されたり、AzureAD単体が持っていないロールバック機能も自分たちで実現することができました。こんな感じで、Serverlessを使って社内のID基盤を構築できました。発表は以上になります。ご清聴ありがとうございました。
（会場拍手）
司会者：ありがとうございます。質問がある方はいらっしゃいますでしょうか？
質問者1：ありがとうございました。いま同じような感じで認証基盤を考えているところなんですけど、例えばAWSのサービスを外部からアクセスさせるかたちで使ったという計画はされたりしていますか？
森岡：そうですね。その計画はしています。
質問者1：その場合、「Intuneを使えば多要素認証とか使えていいですよ」みたいな話をちょっとMSの人から聞いたんですけど、何かそういう感じで考えられていますか？
森岡：そうですね。おっしゃるとおりで、Intuneは採用する予定です。端末管理だったり、そういう用途で入れる予定です。（登壇者注：多要素認証という点では、Microsoft Authenticator などが無料で使えるツールとして提供されています。このあたりのツールについてはセキュリティ要件を作成した後に選ぶと良いと思います）。 AWSに関してもIDaaSを利用してシングルサインオンできるようにする予定で、全社的にもIAMを全部廃止してRoleを使ってアクセスできるようにしようかなと思っています。
質問者1：わかりました。ありがとうございます。
司会者：何かほかに質問のある方はいらっしゃいますか？ では、ありがとうございます。
森岡：ありがとうございます。
（会場拍手）
