KINTO Tech Blog
Event

認証基盤をHENNGEからAzure ADに切り替えた話

rioma
rioma
Cover Image for 認証基盤をHENNGEからAzure ADに切り替えた話

はじめに

こんにちは!KINTOテクノロジーズ(以下、KTC)の開発支援部に所属するriomaです。
普段はコーポレートエンジニアとして「全社利用するITシステムの維持管理」を行っています。
先日、「KINTOテクノロジーズ MeetUp!~情シスによる情シスのための事例シェア4選~」というタイトルで「コーポレートIT領域に特化した、事例発表+座談会形式の勉強会」を開催しました。
今回は、その勉強会で事例発表した内容について、補足を交えながらテックブログ上で紹介します。

登壇の背景

初の社外勉強会を開催しよう!と社内で企画が上がり、ちょうど直近で発表ネタにできそうなPJを経験していたので認証基盤切り替えを実施したというテーマでお話しさせていただきました。
切り替えたのは当社ではなく兄弟会社であるKINTOの環境のお話しですが、スケジュールや当時起きたことなどを交えつつざっくりですがKTCのコーポレートITとして実施していることの紹介ができたと思っています。
この記事では発表時の資料を用いて簡単な補足と、改めて内容のご紹介をいたします。

前提

「なぜ認証基盤切り替えが必要だったのか。」
KINTOでは認証基盤周りの細かい課題が山積みで、利便性とセキュリティの面にいくつか困っていました。
そこでMicrosoft Entra ID(旧Azure AD)を検討したところ最適解となりそうなことからEntra IDへの切り替えを進めることに決定しました。
他の理由としては、KINTOテクノロジーズの認証基盤がすでにEntra IDだったためゆくゆくはテナント統合などの連携強化を見据えて実施しておきたかったという点や、Microsoft E3ライセンスを持っているのに活用できていなかったからといった理由も相まってこの選択になりました。コストカットという面でも大きなメリットがありました。

切り替えにあたって

切り替えにあたって考慮した事項が2つありました。
1つ目は、これまで証明書を利用して制御していたアクセスポリシーを証明書を使わずに同じような条件で実装することです。
条件付きアクセスを利用した設定ですが、概要としては「MDMに登録済みのデバイス」を条件として設定していて、その属性値に当てはまらないものはブロックされるといった設定を組み合わせて既存よりも強化かつ柔軟なアクセスポリシーを実装することができました。

2つ目は、切り替え時に全アカウントのパスワードがリセットされてしまうという仕様があるという点です。
結構強烈なインパクトがある仕様だったのですが、これに対していかに社内のスタッフに影響を出さずに対応するということが求められました。
それにあたって実施したこととしては、システムからの強制リセット後にこちらで一定のルールに基づいて全てのアカウントへのパスワード変更を実施しました。変更ルールはあらかじめ周知しており、ログイン後の詳細手順を合わせて展開していたため当日、ログインできないといった事象は特に発生せず問い合わせ件数もほとんどありませんでした。
※実はほとんどの方はパスワードではなくPINでのログインを利用して入っていたため「変更されたパスワードはこれです」といった周知はそこまで意味がなく逆に少し混乱させてしまうことになった

切り替え作業周辺のトラブル

手順書の展開においてはよくあるケースの一つですが、展開した手順書や作業概要の説明がわかりにくいという声を結構いただいていました。これは私がほぼ100%悪かったのですが、認証基盤切り替えといった大きなインパクトを与える作業のリスクや影響を超丁寧に説明しすぎて普段そのシステムに触らない/意識しない人たちから見るととてもわかりにくいような言葉選びや説明をしてしまったことが反省点です。
そして前述しましたが、切り替え後のPCログインパターンの一つに「PINを入力してログインする」というものがあることに直前まで気づいていませんでした。
事前に展開していた切り替え後のログイン手順書では、そこに全く触れておらず普段PINでログインしている方にとっては「???」となる事態を生んでしまいました。幸い、ギリギリ資料は前日〜当日に直すことができたのですが何度も展開しなおす手間となり混乱を与えてしまいました。。
また切り替え作業中に設計ミスに気づき、設計書と手順書を直しながら切り替え手順を実施するというちょっと無理のある対応もしました。。根幹に関わる部分ではなかったのでそこは助かりました。
他にもあるので添付のスライドをぜひご覧ください。

最後に

細かい問い合わせや指摘はあったものの、何十分も業務ができないといったクリティカルなことは起きなかったようで結論としては無事認証基盤切り替えを実施できました。
のちに「こんな大規模な切り替えなのにあまり問い合わせや業務影響がなかったのはすごい」といった社内のスタッフから声があったと教えていただき、とても嬉しかったです。
今後もシステム変更/切り替えなどは継続して実施していくのでこの経験を踏まえて、よりよい社内環境を構築していきたいです。

Facebook

関連記事 | Related Posts

We are hiring!

【コーポレートエンジニア】コーポレートITG/東京・名古屋・大阪

開発支援部 コーポレートITグループについて開発支援部 コーポレートITグループは生活基盤インフラ(電気・水)をイメージして、スタッフから頼られる必然の存在を目指し、エンジニアリング以外に時間を取られない環境整備​を仕組みで実現していきます。

【部長・部長候補】/プラットフォーム開発部/東京

プラットフォーム開発部 について共通サービス開発GWebサービスやモバイルアプリの開発において、必要となる共通機能=会員プラットフォームや決済プラットフォームの開発を手がけるグループです。KINTOの名前が付くサービスやTFS関連のサービスをひとつのアカウントで利用できるよう、様々な共通機能を構築することを目的としています。