NatureのCorporate ITのマロニーこと瀧澤です。この記事は、第 2 回 Nature Engineering Blog 祭の 8 日目の記事になります。
世間ではついに赤外線リモコン対応家電をMatter連携する世界初のブリッジデバイスが発売されたということでMatter界隈が賑わっていますね！（ダイマ）
うわさのRemo nanoの購入はこちらから→https://www.amazon.co.jp/dp/B0C6V1CJB7
さて、本日のブログはMatterとぜんぜん関係ない話をします。今日は他のメンバーのために率先してハードルを下げるために、昨年から行っていた社内利用のSaaSアカウントの可視化活動について書こうと思います。
SaaSのアカウント管理やっぱり大変だよねという話
これ、すべての情シスの方の共感を得られる話だと思うのですが、弊社でも例に漏れず利用しているSaaSが多岐にわたり、全員が使っているものもあれば職種や領域によって使っているものが異なるなどまちまちです。そうするとどうなるかというと、例えば業務委託やインターン生などが契約満了して離れるとなった時に、この人なんのアカウント持ってたっけ…？ となってしまうわけです。
アカウント管理台帳はスプシで頑張って作っているのですが、メンテし忘れがあったり、利便性のためにアカウント発行をCorporate IT以外のメンバーにもおまかせしているものもあったりして、結局全サービスチェックしに行ったことも。
こういうお悩みに関しては、1つはOktaやAzure AD等のIdP（Identity Provider）を導入してそこで集中管理するというのが挙げられます（ちなみにAzure ADは直近でMicrosoft Entra IDに名称変更されたとのこと）。このやり方はSSOや条件付きアクセス等も同時に実装でき、セキュリティ面の向上やディレクトリ連携によるアカウント作成・削除の効率化などもあわせて達成できるのでとても便利です。一方で、そもそもサービス側がIdP連携に対応してなかったり、IdP連携にはサービス側で上位ライセンスが要求されたり、IdP自体がお高かったりという課題もあります。
別のアプローチとして、とにかくアカウントの可視化をしよう、という考え方からスタートしているサービスもあります。SaaSからAPIでアカウントの状況を持ってきて、サービス側で突き合わせて、誰がなんのサービスを使っているか可視化しようという思想のものです。MoneyForwardのAdminaなどがこれですね。ジョーシスもこちらに近い思想なのではないかと思っています。IdPの場合はIdP側がマスターとなるため、導入にあたって最初にアカウントの状況を整理したりするハードルの高さがあったりするのですが、Admina等の場合はとりあえず導入することでアカウントの状況やシャドーITについて可視化できる、というのもメリットの1つです。
じゃあAdminaやジョーシス導入すればとりあえず解決じゃん！ と思うのですが、小規模な会社だとアカウント管理はまだ手で回せる範囲ではあるため（100人規模ぐらいが1つのボーダーな気がします）、お金という有限のリソースは会社の成長に回したいわけです。世知辛い
とはいえ、楽をしたいミスがなるべく起きないようにしたいというのはあるわけで。Adminaやジョーシスは各種SaaS側が公開しているAPIを使っているサービスであることはサービス説明を聞いて把握できていたので、じゃあもどきを作ってみるか、となったのが昨年の10月ぐらいになります。
作ったもの
GAS（と一部Cloud Function）を使ってこんなのを作りました↓
基本的には、「実行兼ログ溜めシート」に紐づいているGASを定期実行して、各種SaaSのAPIを叩いてその時点で存在しているアカウントの一覧を取得、その情報を現在の「アカウント管理台帳」の情報と突き合わせて、アカウント情報にアップデートがある場合は「アカウント管理台帳」を更新する（追加、変更、ステータスとしての削除）、ということをやらせています。
APIの認証情報はGASの環境変数に埋め込んで、そのGASにアクセスできる人の権限は共有ドライブの権限で絞っています。権限管理がファイル管理に紐づいて直感的な点はGASの利点の1つだなと思いました。
また、何より無料！無料は正義ですよ！
苦労話その1、GASのライブラリについて
GASは言語的にはJavascriptなのでnode.jsと同じような感じで書いてたのですが、ちょっと調べれば便利なライブラリが出てきて気軽にインストールできるnode.jsと違って、GASではインストールにもひと癖ある上、そもそもどんなライブラリがあるのか調べるのも困難、ということが難点ですね（参考、読めばわかるが、使いこなせるとは言っていない）。特に今回の要件だとAPIをコールするためのライブラリやJWT（Json Web Token）を生成するライブラリが使えないのが困りました。
前者はデフォで使えるUrlFetchAppで書いてどうにかしました。こいつも癖が結構あるのですがまぁ割愛。後者も頑張ってベタ書きしたのですが、AppStoreConnectの場合、暗号化にES256使えと言われます。これだけはJsonWebToken使わずにやるのがどうしても無理だったので、ここだけCloud Function + Node.jsで実装することにしました。まぁコール数的にかかっても月数十円ぐらいなので。。（弊社のつよつよエンジニアの桒山さんならベタ書きできるかもしれませんが、なんちゃってエンジニアの私では無理無理カタツムリ）
苦労話その2、APIのトークンについて
この辺のSaaSのAPIのトークンは、①恒久的なアプリトークンを発行してそれを使い続ける、②OAuth方式でrefresh tokenを発行して、refresh tokenから都度有効期限のあるaccess tokenを発行して使う、③jwtでトークンを作成する、といった方法があります。セキュリティ等の関係から、エンプラ系サービスのAPIの認証方式として多いのは② >= ③ > ①かなぁという印象ですが、まぁ今回は主に②を利用し、SaaS側で③が要求されるケース（githubやAppStoreConnectなど）は③を使って実装していました。
②の方式も準備はいろいろといるのですが、一度refresh tokenを発行できれば基本的にはこのrefresh tokenは半永久的に（こちらから能動的にrevokeしない限り）使い続けることができるのでメンテいらずです。ただし、SaaS側の実装によってはこのrefresh token、Access Tokenの取得ごとに再発行される場合があります。今回対応したSaaSの中だと、Microsoft 365（Office 365）のGraph APIとfreee APIが該当しました。
なので、これらについてはGASの環境変数に埋め込んでいるSecret情報を都度更新するロジックを追加で書いてます。
使ってみて
週に1回ペースで定期実行しています。
動作したログはスプシに吐き出すようにしていて、台帳の何行目がどういう形でアップデートされたかを記録するようにしています。こんな感じ↓
（Slackは表示名の変更もキャッチするようにしちゃってるのでログが多いです）
現状のプランでAPIが使えるSaaS限定とはなりますが、台帳だけ追っていれば良くなったのは非常に気が楽ですね。管理にかけるリソース（時間・集中力等）を大分削ることができました。
現在は、これに追加でアカウントの作成・削除の機能なども付け足したりしつつ運用しています。
実は今年の4月からCorporate IT以外のことにリソースを8〜9割持っていかれているので、早めにこういう整備をしておいてよかったなぁと今になって思っています。
以上、アカウント管理周りは、システムで可視化・管理効率化できていると幸せになれるよ、というお話でした。
おまけ
とはいえこれ人や利用サービスがさらに増えたらメンテナンスどうすんねんという話があります。
なので、どっかのタイミングでAdmina等のちゃんとしたエンプラサービスいれたいですね。世間の情シスのみなさんも、上司や会社を頑張って説得しましょう！
Nature開発者Community
Natureのプロダクトに関する開発者向けの情報を交換する場として、 Nature開発者コミュニティ をDiscord上に立ち上げています。
matter チャネルもありますので、Remo nanoとMatterの開発に関することなど、気軽にご質問いただければと思います。
Nature Matter Kaigi
07/19(水)に、日本企業初のMatter製品「Nature Remo nano」の販売を記念して、まだまだ日本では盛り上がり足りないMatterを盛り上げていこう！の会「Nature Matter Kaigi」を開催します。 ユカイ工学株式会社様よりゲストをお招きし、Nature Remo nano の開発メンバーとMatter 入門話やMatter苦労話などをする予定です。 Matter がちょっと気になる方、是非ご参加ください！
