#11」が開催されました。Architectureやその周辺技術について情報を共有する本コミュニティ。今回は、株式会社Speeeのオフィスにて、6人のエンジニアがLTを行いました。森岡周平氏(以下、森岡):それでは、「Serverlessで構築する社内ID基盤」というテーマで、株式会社Speee開発基盤ユニットの森岡から発表させていただきます。Platformを利用してServerlessでID基盤を構築したことについてお話をさせていただきます。今回ID基盤を構築してIDaaSにAzureADを利用したんですが、「どうしてAzureADを利用したのか?」という話だったり、AzureADの細かい話については勉強会のテーマとそぐわないのでお話をしません。GCPでServerless開発をする上でのTipsなどについても時間の関係でカットさせていただきます。興味のある方がいましたら、あとで質問していただけたら回答しますのでお聞きください。今日の発表ですが、こんな感じのアジェンダで説明させていただきます。あらためまして、株式会社Speeeの開発基盤ユニットで仕事をしている森岡です。最近の業務はこんな感じのものがありまして、本日お話しするID基盤を構築するきっかけとなったIDaaSの導入を、現在は業務として進めております。IDaaS導入の背景このIDaaSを導入しようと思った背景についてお話させていただきます。Meetup」という勉強会でお話しさせていただいたのですが、僕がSpeeeの開発基盤ユニットで最初にやった仕事は、全社で統一する監視ツールの選定と導入でした。これを進めた結果、監視ツールが全部統一されたので、監視に対するナレッジが社内で共有されていったということがあって、すごく便利なんですけれども。一方で問題点として、開発基盤ユニットが管理しなきゃいけないツールがどんどん増えていったんです。開発基盤ユニットは当時僕1人で、AWS、SendGrid、Datadog、なんちゃらかんちゃら......、みたいなやつを全部僕1人で管理していて、「とてもじゃないけど手が回らないぞ」という感じになって、IDaaSの導入を考え始めました。急にIDaaSって話をしちゃったのですが、IDaaSって聞いたことのある方、この中にどれぐらいいらっしゃいますか?(会場挙手)あ、けっこういました。ありがとうございます。IDaaSとは何か?基本的に、IDaaSって言われても、たぶんセキュリティとか情シスの方以外はあんまり馴染みのない言葉かなと思うんですが、たぶんみなさんも使ったことはあると思うんですよね。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がいるの!?」みたいな感じでみんなびっくりだと思うんですけれども、こんな感じの構成にしました。FunctionsでAzureADにデータを突っ込むみたいな流れになっています。本当はもっと細かい要素がたくさんあるんですけど、今回は単純にわかりやすくするためにこのように端折って図を作りました。後で細かくお話をしていきます。さっきの構成図を見たら「なんであんな簡単なことをするのに、こんな変なことするの?」と気になると思うんですけれども、その理由についてこれから説明していきます。システム要件まずIDaaSにデータを投入したかったので社員マスタが欲しかったんですけど、人事の人が管理している社員マスタには、評価などのとても機密性が高い情報がたくさん含まれていて、気軽にエンジニアが開発に使えなかったんですね。気軽に開発がしたかったので、社員マスタからIDaaSに必要な情報だけ抽出したかったんです。そんなことができるようなシステムは社内になかったので、自分で作るしかありませんでした。そもそも社員マスタ自体の運用が固まっていなかったことで、過去に事故が起こったこともあったんですね。いう事故かというと、例えば昔いた人と同じ名前の人が入社したときに、同じメールアドレスを付与しちゃったみたいな。これはすぐ気づいてすぐ対応されたので大丈夫だったんですけれども、手運用しているとそういう障害が起きたりします。いう問題が起きないように、信頼できる社員マスタを作る必要がありました。いうことで、今回作るシステムの要件がこちらになります。すごい機密情報を持っているので、社員マスタ自体に直接触れることができるエンジニアはごく少数にします。その上で社員マスタからIDaaSに必要なデータのみ整形・抽出できるようにします。IDaaSのシステムはこのデータをセキュアにアクセスできるようにして、そのデータをもとに自身の従業員のデータを更新するようにします。このような運用をするにあたって、人事の方の作業を大きく変えてしまうと混乱が発生するので、人事の方は何も手を加えずにこのようなことができるようにしました。このIDaaSとは別文脈で、ほかのサービスでもこの社員マスタを使いたいみたいな要望があとで来たので、ここも対応できるようなシステムにする必要がありました。システムの流れさっきの図をちょっとかっこよくすると、こんな感じの図になります。Makerにアクセスして反映する手続きを取りにいきます。Functionsが各種社内サービスにアクセスしにいってデータを取得します。そのデータに対してValidationを行います。このValidationというのは、先ほどお話しした「同一メールアドレスが存在していないか?」であったり。あとは社員マスタって自動化に使われることを想定しないので、よくジョブタイトルに「社員」「_社員」とあったり、データがすごいごちゃごちゃしているので、こういうものがないかを確認していきます。Validationの結果と変更内容を人事の方に提示して、問題がなければSubmitボタンを押してもらいます。Storageにアップロードされます。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を採用しています。Functionsを使ってIDaaSに反映していきます。Functionsが自動で起動します。APIを使ってAuzureADのデータを更新します。Suiteにも同期されるようになっています。従業員は、AzureADにアクセスして、そこからAWSだったりSalesforce、DatadogだったりにSSOするようなかたちになっています。このシステムを作るにあたって注意した点なんですけれども、BigQueryのViewを常に正としてIDaaSのデータを更新します。BigQueryのViewの内容をもうそのまま全部突っ込む。BigQueryのデータをそのまま入れられるようにする感じです。なんでこうしたのかというと、冪等性を担保したかったんです。Functionsなので何回も実行されてしまうみたいなことが、多分にあると思うんです。そのときに必ずBigQueryと同じかたちのデータにすることが決まっていたら冪等性が担保できるかなと思って、このようにしています。万が一問題があったとして、ロールバックしなければいけないとなったときに、過去のデータを参照するようにすれば、すぐにロールバックができるようになっています。AzureAD自体にはロールバックみたいな機能がないので、こういうかたちでロールバックを実現しています。あともう1つ、AzureAD上では必ず従業員を消さないようにしているのが1点の工夫ポイントです。なんでかというと、先ほどお話ししたメールアドレスの重複登録の対策です。先ほどの社員マスタ作成時にも一応Validationでチェックはしているのですが、これはすごくセキュリティ的に問題があるものなので、AzureAD上でもチェックして必ずダブルチェックをするようにしています。このAzureADなのですが、従業員数課金ではなくてライセンス数課金なので、いくらでも従業員を登録できます。退職者のデータも保持しておくことで、メールアドレスが重複しないように検査しています。Makerここはおまけなのですが、人事の人が触るアプリケーションの説明です。Makerというものを使っています。これはUI操作で簡単な静的サイトが作成できるようなものなんですけれども、「Speee.jpドメインのメールアドレスを持っているユーザーしか触れない」のように閲覧者の設定が細かくできるので、一定セキュアな静的サイトが作れたりします。Functionsを実行して、データのDiffを見れるようにしています。何が更新されたのかを見て、問題なければ反映するみたいな手続きを取っています。IDaaSの基盤を作るにあたって、ほとんど既存の運用を変えずに、運用コストを増やさずむしろ削減して実現することができました。BigQueryを利用してセキュアでスケールする社員マスタが構築できました。常にバックアップが取られているので、人事系SaaSへの依存度が大きく減少しています。IDaaS以外のツールもViewで切り出せば簡単に連携できるようになっているのと、BigQueryの料金はたまっているデータ量とクエリで操作する量に依存するので、社員ぐらいのデータじゃほとんどお金がかからないんですよね。いうことで、BigQueryは無料枠で利用できています。BigQueryを正としてIDaaSにデータを反映することによって、冪等性が担保されたり、AzureAD単体が持っていないロールバック機能も自分たちで実現することができました。こんな感じで、Serverlessを使って社内のID基盤を構築できました。発表は以上になります。ご清聴ありがとうございました。(会場拍手)司会者:ありがとうございます。質問がある方はいらっしゃいますでしょうか?質問者1:ありがとうございました。いま同じような感じで認証基盤を考えているところなんですけど、例えばAWSのサービスを外部からアクセスさせるかたちで使ったという計画はされたりしていますか?森岡:そうですね。その計画はしています。質問者1:その場合、「Intuneを使えば多要素認証とか使えていいですよ」みたいな話をちょっとMSの人から聞いたんですけど、何かそういう感じで考えられていますか?森岡:そうですね。おっしゃるとおりで、Intuneは採用する予定です。端末管理だったり、そういう用途で入れる予定です。無料で使えるツールとして提供されています。このあたりのツールについてはセキュリティ要件を作成した後に選ぶと良いと思います)。AWSに関してもIDaaSを利用してシングルサインオンできるようにする予定で、全社的にもIAMを全部廃止してRoleを使ってアクセスできるようにしようかなと思っています。質問者1:わかりました。ありがとうございます。ありがとうございます。森岡:ありがとうございます。Community(JP)に関する記事をまとめています。Community(JP)に関する新着記事が公開された際に、通知を受け取ることができます。