$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
HENNGEからAzure ADへの認証基盤切り替えをした話
Search
KTCコーポレートITグループ
August 03, 2023
Technology
4
2k
HENNGEからAzure ADへの認証基盤切り替えをした話
【第1回】KINTOテクノロジーズ MeetUp!での登壇資料です。
イベントURL:
https://kinto-technologies.connpass.com/event/289977/
KTCコーポレートITグループ
August 03, 2023
Tweet
Share
More Decks by KTCコーポレートITグループ
See All by KTCコーポレートITグループ
たった1人からはじめる【Agile Community of Practice】~ソース原理とFearless Changeを添えて~
ktc_corporate_it
2
1.1k
アジャイルな情シスやってみた(v2)
ktc_corporate_it
1
340
アジャイルな情シスやってみた
ktc_corporate_it
1
620
Bookingsで健康診断予約改善してみた
ktc_corporate_it
0
340
Jiraでやったった!無人備品貸出なしくみ
ktc_corporate_it
0
390
セルフブランディングのススメ
ktc_corporate_it
0
250
一時アクセスパス機能のご紹介
ktc_corporate_it
0
290
KINTOとKINTOテクノロジーズのヘルプデスクが連携した(していっている)お話
ktc_corporate_it
0
150
Windowsキッティング自動化のススメ
ktc_corporate_it
0
280
Other Decks in Technology
See All in Technology
ファインディの4年にわたる技術的負債の返済 / Repaying 4 Years of Technical Debt at Findy
ma3tk
5
1.5k
【CNDW2024】SIerで200人クラウドネイティブのファンを増やした話
yuta1979
1
280
SLMをエッジAIとして検証してみて分かったこと
iotcomjpadmin
0
300
Amazon CloudFrontを活用したゼロダウンタイム実現する安定的なデプロイメント / 20241129 Yoshiki Shinagawa
shift_evolve
0
120
2024/11/29_失敗談から学ぶ! エンジニア向けre:Invent攻略アンチパターン集
hiashisan
0
260
LLMアプリケーションの評価と継続的改善
pharma_x_tech
3
180
【ASW21-01】STAMPSTPAで導き出した課題に対する対策立案手法の提案
hianraku9498
0
180
Microsoft Ignite 2024 Update 2 - AIとIoT関連の最新情報をどこよりも早く!
iotcomjpadmin
0
290
偶有的複雑性と戦うためのアーキテクチャとチームトポロジー
knih
7
6k
PFN Company Deck
pfn
PRO
2
140
次のコンテナセキュリティの時代 - User Namespace With a Pod / CloudNative Days Winter 2024
pfn
PRO
5
440
複雑なCI/CDから脱却したアーキテクチャ:NTTグループの内製プラットフォーム事例を通して / An Architecture Achieving Simplified CI/CD: Insights from NTT Group's In-House Platform Case Study
nttcom
0
150
Featured
See All Featured
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Making Projects Easy
brettharned
115
5.9k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Adopting Sorbet at Scale
ufuk
73
9.1k
Building Adaptive Systems
keathley
38
2.3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
27
4.3k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
27
2.1k
Transcript
1 HENNGEからAzureADへの 認証基盤切り替えをした話 202307
名前:Rio Maruyama 経歴:⼤学卒業後、未経験で⽂系SEとしてITベンチャー企業に就職。 約3年半勤めた後、2023年4⽉にKINTOテクノロジーズ株式会社へ⼊社。 専⾨的な技術領域:主にM365、Azure AD,MDM周辺の領域に携わる。 趣味:⾟いものを⾷べること、猫を愛でること 2 ⾃⼰紹介 2019/04
2023/04 KINTOテクノロジーズ 株式会社 (SW開発/コーポレートIT) 某ベンチャー会社 (SES/Microsoft系エンジニア)
• ヘルプデスク • キッティング • 資産管理 ヘルプデスク • インフラ管理 ITサポート
⾃⼰紹介 ITチーム • ヘルプデスク等のフロント対応 Tech Service • 定形的な運⽤対応 Infra Support • 社内IT基盤の活⽤と課題解決の仕組みづくり Corporate Engineering • 関係会社⽀援 Enterprise Technology • コーポレートITグループの課題解決エンジン Boost コーポレートITグループ 丸⼭はここ 3
『認証基盤切り替えをした話』 KINTOでは今年の4⽉に認証基盤をHENNGE Access ControlからAzure ADへと切り替えました。 影響を受けるアカウント総数は300~400と決して少なくない中で、いかに影響を出さず⼯夫した点や苦労し た点などをご紹介します。 また、なぜ認証基盤切り替えを実施するにいたったかの背景や社員から実際にあった問い合わせ、切り替え 直後のドタバタなど⾚裸々にお話しします。 💡⽬次💡
1. 認証基盤切り替えの背景 2. 切り替えにあたっての考慮事項 3. 体制や計画 4. 切り替え作業周辺の出来ごと 5. まとめ 4 はじめに
5 認証基盤切り替えの背景
理由その1 ID周りの既存課題を解決するのにAzure ADが最適解だったから (HENNGE Access Controlでは限界を感じた) 6 なぜ認証基盤の切り替えが必要だったのか 既存課題 解決策
各Webサービスでパスワードのセキュリティレベルが統⼀できて いない。 統合できたアカウントについては、 統合認証で指定したパスワードセキュリティが適⽤される セキュリティ監査等により、Webサービスへのログイン履歴を 確認する場合、Webサービス毎に確認する必要がある。 統合認証に対応したサイトについては、ログイン情報が集 約され、Webサービス毎に確認する必要がなくなる。 ユーザーがパスワードを忘れたら、管理者がパスワードリセット するまで当該サイトが利⽤できず、業務停⽌となる。 統合できたアカウントについては、 ユーザー⾃⾝がパスワードを再設定することができる。 現在利⽤しているID/パスワードが、実は既に流出している 可能性があるが、それを確認することはできない。 統合できたアカウントについては、MS社のナレッジにより、 流出しているID/パスワードの利⽤時は通知される。 特権アカウントで厳重なログインの管理ができていない。 (⼀般ユーザーと同じ) 特権アカウントはモバイルデバイスを利⽤した 多要素認証を必須とする等、本⼈確認を厳重にする 〇 〇 〇 〇 〇 〇 〇 〇 〇 統合認証環境を利⽤し、ID/パスワードを統合していく。 (統合認証に対応しているもののみ) PC と各Web サービスで利⽤する ID/パスワード がバラバラになっている。
理由その2 パートナー会社の認証基盤がAzure ADだったため ゆくゆくはAzure ADテナント統合 などの連携強化を⾒据えて実施しておきたかった 理由その3 Microsoft E3ライセンスを持っているのに活⽤できていなかったから、、 (せっかくあるのにライセンス料もったいない)
7 なぜ認証基盤の切り替えが必要だったのか
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アカウント
切り替え後の環境 Internet KINTO 社内 外部ネットワーク ※Access Control IP制限、証明書認証 社内 NW
デバイス Intune 管理 Intune 条件付きアクセス (IP 制限・Intune 準拠チェック) Microsoft 365 認証連携 (SAML) SaaS メール セキュリティシステム
10 切り替えにあたっての 考慮事項
①アクセスポリシーの再設計 HENNGEで実現していたアクセスポリシーを⾒直す必要があった。 11 切り替えにあたって 考慮事項 HENNGE Accsess Controll アクセスポリシー ①
デバイス証明書を配布したPCは弊社M365環境へのアクセス可能 ② 指定したIP以外からのアクセスをブロック(IP制限) Azure AD アクセスポリシー ① 多要素認証の強制 ② Intune(MDM)に登録されているデバイスからのみ弊社M365環境アクセス可能 ③ アプリごとのアクセス制限など etc 細かいアカウント種別ごとに細かいルールを設定できるようになった AzureAD 条件付きアクセスへの移⾏
②切り替え時のスタッフ影響を極限まで減らすこと 切り替えにあたって、全アカウントのパスワードがリセットされるという仕様があった。 そのため以下を事前に実施した。 12 切り替えにあたって 考慮事項 パスワードが変更されることを(しつこいくらいに)社内周知 変更後のログイン挙動について詳細の⼿順書を事前に展開 当⽇は各オフィス、営業所にヘルプデスクメンバー最低⼀⼈を配置 変更後のパスワードを事前周知
(⽒名+特定の⽂字列といったルールでアカウントごとに設定)
13 スケジュールや 作業体制の紹介
14 ざっくりスケジュール 1 ⽉ 2 ⽉ 3 ⽉ 4⽉ 会議
設計 構築・テスト 認証基盤切替 その他 Microsoft 365 設計 運⽤設計 ・ユーザーマニュアル作成 ・管理者マニュアル作成 Azure AD 条件付きアクセス 設定・テスト・有効化 SaaS 認証連携(SSO)検証 ⭐認証基盤 切替 ヘルプデスクメンバーへの 運⽤連携 定例会(隔週) フォロー期間 切替設計 2023年1⽉下旬〜4⽉下旬(3ヶ⽉)
PJ体制はこんな感じ 15 体制 弊社 業務委託 1名 プロジェクトマネージャー 1名 技術責任者 1名
メンバー 1名 プロジェクト責任者 1名 プロジェクトマネージャー 2名 サポートメンバー 丸⼭ プロジェクト推進担当 計:11名 (6名) ヘルプデスクメンバー 計:3名
ベンダー作業の⼀部を内製化することで、業務委託のコストを削減(20%ほど) ⇨KINTO/KTCは今後も内製化を⽬指していく 超ざっくりやったこと⼀覧 16 ベンダー利⽤について 作業 説明 移⾏設計 HENNGE Access
ControlからAzure ADに認証を変更するための設計 基本設計 Azure ADの詳細設計を⾏うための基本的な設計 詳細設計 Azure ADの設定を⾏うためのパラメータ設計 設定作業 詳細設計で設計した内容を元に設定 切替作業 HENNGE OneからAzure ADに認証の切替 クラウド連携⽀援 SAMLに対応したクラウドサービスとの連携 問合せ⽀援 Azure AD統合に関するQA対応 ユーザー向け変更点説明資料作成 Azure ADへの統合に伴い既存環境から変更される箇所について ユーザーへの簡易説明資料作成 管理者向け運⽤マニュアル作成 管理者が運⽤で利⽤するマニュアル作成
17 切り替え作業周辺のトラブル
その1 切り替え前の段階で「⼿順書がわかりにくすぎる!」「こちら側への影響がよくわからない」 との問い合わせを多数いただいてしまった 反省:エンジニア的な視点/切り替え作業者の視点を資料やアナウンス⽂に盛り込み過ぎてしまった。 情報過多。スタッフ⽬線での不安なポイントや簡潔に実施して欲しいことを重視するべきだった。 その2 切り替え後のログインケースの想定が抜けていたことにギリギリで気づく 何かというと… 切り替え後のログイン動作として 「PCを起動してパスワードを⼊⼒してログインする」を想定していた、、が
「PCを起動してPINを⼊⼒してログインする」というケースが考慮漏れ。 これによって何がまずかったか… 事前のアナウンスで『切り替え後は変更されたパスワードでログインしてください!』を徹底していたため PINの⼊⼒画⾯で⼊ろうとしたスタッフが間違ったものを⼊⼒してしまうというリスクが発⽣してしまった。 ⇨慌てて展開資料の修正とアナウンスを修正 18 切り替え作業周辺のトラブル
その3 切り替え作業当⽇に設計のミスに気づく アクセスポリシーの⼀つにデバイスの種別による制限を設けていたが ブロックしているデバイスの利⽤ケースがあることに気づいてしまった。 ⇨慌てて関係者に連絡して、⽅針をすり合わせ設計を修正(ギリギリセーフ。。) その4 社⻑から「アクセスできない」との問い合わせをもらってしまう ⇨秘書の⽅に速攻連絡して対応、、、 反省:役職者たちへの事前のアナウンスが不⼗分だった その5
事前資料に展開しているURLが間違っていたことに当⽇気づく SAML連携したアプリのSSO⽤のURLが間違っていた ⇨「⼿順書通りにいかない」という多くの問い合わせで気づき急ピッチで資料を修正 19 切り替え作業周辺のトラブル
20 まとめ
21 まとめ どんなメリットあったか ①PCログオンとAzure ADと連携可能なSaaS製品のログインを統合 ⇨セキュリティレベルを維持したままで、各種SaaSログインを省略 ②セルフサービスパスワードリセットの実装 ⇨ユーザーが⾃分⾃⾝でパスワードをリセット可能になり、IT管理者の負荷低減 ③条件付きアクセスの実装 ⇨柔軟なアクセス許可の設定が可能になりセキュリティの強化
ex)iP(場所),サインイン頻度,時間,端末…etc で条件を設定できる ④パートナー会社と同じ認証基盤化 ⇨今後の連携のための⼟台作り/効率化/スピードUP ⑤ライセンス費⽤削減 HENNGEライセンス料⾦+デバイス証明書代 ⇨年間約240万円のコストカットに成功 結論 切り替え⾃体は成功 当⽇の問い合わせ0件!といった理想的な状態ではなかったものの スタッフにクリティカルな業務影響は発⽣しなかった。
None