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

【第1回】KINTOテクノロジーズ MeetUp！での登壇資料です。
イベントURL：https://kinto-technologies.connpass.com/event/289977/

Transcript

1. 1 HENNGEからAzureADへの 認証基盤切り替えをした話 202307
2. 名前：Rio Maruyama 経歴：⼤学卒業後、未経験で⽂系SEとしてITベンチャー企業に就職。 約3年半勤めた後、2023年4⽉にKINTOテクノロジーズ株式会社へ⼊社。 専⾨的な技術領域：主にM365、Azure AD,MDM周辺の領域に携わる。 趣味：⾟いものを⾷べること、猫を愛でること 2 ⾃⼰紹介 2019/04 2023/04 KINTOテクノロジーズ 株式会社 （SW開発/コーポレートIT) 某ベンチャー会社 (SES/Microsoft系エンジニア)
3. • ヘルプデスク • キッティング • 資産管理 ヘルプデスク • インフラ管理 ITサポート ⾃⼰紹介 ITチーム • ヘルプデスク等のフロント対応 Tech Service • 定形的な運⽤対応 Infra Support • 社内IT基盤の活⽤と課題解決の仕組みづくり Corporate Engineering • 関係会社⽀援 Enterprise Technology • コーポレートITグループの課題解決エンジン Boost コーポレートITグループ 丸⼭はここ 3
4. 『認証基盤切り替えをした話』 KINTOでは今年の4⽉に認証基盤をHENNGE Access ControlからAzure ADへと切り替えました。 影響を受けるアカウント総数は300~400と決して少なくない中で、いかに影響を出さず⼯夫した点や苦労し た点などをご紹介します。 また、なぜ認証基盤切り替えを実施するにいたったかの背景や社員から実際にあった問い合わせ、切り替え 直後のドタバタなど⾚裸々にお話しします。 💡⽬次💡 1. 認証基盤切り替えの背景 2. 切り替えにあたっての考慮事項 3. 体制や計画 4. 切り替え作業周辺の出来ごと 5. まとめ 4 はじめに
5. 5 認証基盤切り替えの背景
6. 理由その１ ID周りの既存課題を解決するのにAzure ADが最適解だったから (HENNGE Access Controlでは限界を感じた) 6 なぜ認証基盤の切り替えが必要だったのか 既存課題 解決策 各Webサービスでパスワードのセキュリティレベルが統⼀できて いない。 統合できたアカウントについては、 統合認証で指定したパスワードセキュリティが適⽤される セキュリティ監査等により、Webサービスへのログイン履歴を 確認する場合、Webサービス毎に確認する必要がある。 統合認証に対応したサイトについては、ログイン情報が集 約され、Webサービス毎に確認する必要がなくなる。 ユーザーがパスワードを忘れたら、管理者がパスワードリセット するまで当該サイトが利⽤できず、業務停⽌となる。 統合できたアカウントについては、 ユーザー⾃⾝がパスワードを再設定することができる。 現在利⽤しているID/パスワードが、実は既に流出している 可能性があるが、それを確認することはできない。 統合できたアカウントについては、MS社のナレッジにより、 流出しているID/パスワードの利⽤時は通知される。 特権アカウントで厳重なログインの管理ができていない。 （⼀般ユーザーと同じ） 特権アカウントはモバイルデバイスを利⽤した 多要素認証を必須とする等、本⼈確認を厳重にする 〇 〇 〇 〇 〇 〇 〇 〇 〇 統合認証環境を利⽤し、ID/パスワードを統合していく。 （統合認証に対応しているもののみ） PC と各Web サービスで利⽤する ID/パスワード がバラバラになっている。
7. 理由その２ パートナー会社の認証基盤がAzure ADだったため ゆくゆくはAzure ADテナント統合 などの連携強化を⾒据えて実施しておきたかった 理由その3 Microsoft E3ライセンスを持っているのに活⽤できていなかったから、、 (せっかくあるのにライセンス料もったいない) 7 なぜ認証基盤の切り替えが必要だったのか
8. 8 切り替え前の環境 ：外部からのメール受信 ：外部へのメール送信 ：M365 利⽤の通信 <凡例> ：認証連携 Internet Azure AD 社内 外部ネットワーク 送信元 メール攻撃対策 ：メール、スケジュー ル ＜機能概要＞ ：Web 会議、チャッ ト メール セキュリティ Exchange Teams Microsoft 365 Exchange Online Teams 送信先 証明書登録デバイス ※Access Control IP 制限、証明書認証 SharePoint 認証連携 社内 NW デバイス Access Control ：認証制御 ：ファイルサーバー SharePoint Online Intune 管理 Intune管理 Intune ：デバイス管理（MDM） Intune ：プロジェクトの対象範囲 認証連携（SAML） ⭐Azure ADを全く使っていないわけではなかった SaaS メール セキュリティシステム 300~400アカウント
9. 切り替え後の環境 Internet KINTO 社内 外部ネットワーク ※Access Control IP制限、証明書認証 社内 NW デバイス Intune 管理 Intune 条件付きアクセス （IP 制限・Intune 準拠チェック） Microsoft 365 認証連携 （SAML） SaaS メール セキュリティシステム
10. 10 切り替えにあたっての 考慮事項
11. ①アクセスポリシーの再設計 HENNGEで実現していたアクセスポリシーを⾒直す必要があった。 11 切り替えにあたって 考慮事項 HENNGE Accsess Controll アクセスポリシー ① デバイス証明書を配布したPCは弊社M365環境へのアクセス可能 ② 指定したIP以外からのアクセスをブロック(IP制限) Azure AD アクセスポリシー ① 多要素認証の強制 ② Intune(MDM)に登録されているデバイスからのみ弊社M365環境アクセス可能 ③ アプリごとのアクセス制限など etc 細かいアカウント種別ごとに細かいルールを設定できるようになった AzureAD 条件付きアクセスへの移⾏
12. ②切り替え時のスタッフ影響を極限まで減らすこと 切り替えにあたって、全アカウントのパスワードがリセットされるという仕様があった。 そのため以下を事前に実施した。 12 切り替えにあたって 考慮事項 パスワードが変更されることを(しつこいくらいに)社内周知 変更後のログイン挙動について詳細の⼿順書を事前に展開 当⽇は各オフィス、営業所にヘルプデスクメンバー最低⼀⼈を配置 変更後のパスワードを事前周知 (⽒名＋特定の⽂字列といったルールでアカウントごとに設定)
13. 13 スケジュールや 作業体制の紹介
14. 14 ざっくりスケジュール 1 ⽉ 2 ⽉ 3 ⽉ 4⽉ 会議 設計 構築・テスト 認証基盤切替 その他 Microsoft 365 設計 運⽤設計 ・ユーザーマニュアル作成 ・管理者マニュアル作成 Azure AD 条件付きアクセス 設定・テスト・有効化 SaaS 認証連携(SSO)検証 ⭐認証基盤 切替 ヘルプデスクメンバーへの 運⽤連携 定例会（隔週） フォロー期間 切替設計 2023年1⽉下旬〜４⽉下旬(３ヶ⽉)
15. PJ体制はこんな感じ 15 体制 弊社 業務委託 1名 プロジェクトマネージャー 1名 技術責任者 1名 メンバー 1名 プロジェクト責任者 1名 プロジェクトマネージャー 2名 サポートメンバー 丸⼭ プロジェクト推進担当 計：11名 (6名) ヘルプデスクメンバー 計：3名
16. ベンダー作業の⼀部を内製化することで、業務委託のコストを削減(20％ほど) ⇨KINTO/KTCは今後も内製化を⽬指していく 超ざっくりやったこと⼀覧 16 ベンダー利⽤について 作業 説明 移⾏設計 HENNGE Access ControlからAzure ADに認証を変更するための設計 基本設計 Azure ADの詳細設計を⾏うための基本的な設計 詳細設計 Azure ADの設定を⾏うためのパラメータ設計 設定作業 詳細設計で設計した内容を元に設定 切替作業 HENNGE OneからAzure ADに認証の切替 クラウド連携⽀援 SAMLに対応したクラウドサービスとの連携 問合せ⽀援 Azure AD統合に関するQA対応 ユーザー向け変更点説明資料作成 Azure ADへの統合に伴い既存環境から変更される箇所について ユーザーへの簡易説明資料作成 管理者向け運⽤マニュアル作成 管理者が運⽤で利⽤するマニュアル作成
17. 17 切り替え作業周辺のトラブル
18. その１ 切り替え前の段階で「⼿順書がわかりにくすぎる！」「こちら側への影響がよくわからない」 との問い合わせを多数いただいてしまった 反省：エンジニア的な視点/切り替え作業者の視点を資料やアナウンス⽂に盛り込み過ぎてしまった。 情報過多。スタッフ⽬線での不安なポイントや簡潔に実施して欲しいことを重視するべきだった。 その２ 切り替え後のログインケースの想定が抜けていたことにギリギリで気づく 何かというと… 切り替え後のログイン動作として 「PCを起動してパスワードを⼊⼒してログインする」を想定していた、、が 「PCを起動してPINを⼊⼒してログインする」というケースが考慮漏れ。 これによって何がまずかったか… 事前のアナウンスで『切り替え後は変更されたパスワードでログインしてください！』を徹底していたため PINの⼊⼒画⾯で⼊ろうとしたスタッフが間違ったものを⼊⼒してしまうというリスクが発⽣してしまった。 ⇨慌てて展開資料の修正とアナウンスを修正 18 切り替え作業周辺のトラブル
19. その３ 切り替え作業当⽇に設計のミスに気づく アクセスポリシーの⼀つにデバイスの種別による制限を設けていたが ブロックしているデバイスの利⽤ケースがあることに気づいてしまった。 ⇨慌てて関係者に連絡して、⽅針をすり合わせ設計を修正(ギリギリセーフ。。) その４ 社⻑から「アクセスできない」との問い合わせをもらってしまう ⇨秘書の⽅に速攻連絡して対応、、、 反省：役職者たちへの事前のアナウンスが不⼗分だった その５ 事前資料に展開しているURLが間違っていたことに当⽇気づく SAML連携したアプリのSSO⽤のURLが間違っていた ⇨「⼿順書通りにいかない」という多くの問い合わせで気づき急ピッチで資料を修正 19 切り替え作業周辺のトラブル
20. 20 まとめ
21. 21 まとめ どんなメリットあったか ①PCログオンとAzure ADと連携可能なSaaS製品のログインを統合 ⇨セキュリティレベルを維持したままで、各種SaaSログインを省略 ②セルフサービスパスワードリセットの実装 ⇨ユーザーが⾃分⾃⾝でパスワードをリセット可能になり、IT管理者の負荷低減 ③条件付きアクセスの実装 ⇨柔軟なアクセス許可の設定が可能になりセキュリティの強化 ex)iP(場所),サインイン頻度,時間,端末…etc で条件を設定できる ④パートナー会社と同じ認証基盤化 ⇨今後の連携のための⼟台作り/効率化/スピードUP ⑤ライセンス費⽤削減 HENNGEライセンス料⾦＋デバイス証明書代 ⇨年間約240万円のコストカットに成功 結論 切り替え⾃体は成功 当⽇の問い合わせ0件！といった理想的な状態ではなかったものの スタッフにクリティカルな業務影響は発⽣しなかった。