$30 off During Our Annual Pro Sale. View Details »

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

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

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

More Decks by KTCコーポレートITグループ

Other Decks in Technology

Transcript

  1. • ヘルプデスク • キッティング • 資産管理 ヘルプデスク • インフラ管理 ITサポート

    ⾃⼰紹介 ITチーム • ヘルプデスク等のフロント対応 Tech Service • 定形的な運⽤対応 Infra Support • 社内IT基盤の活⽤と課題解決の仕組みづくり Corporate Engineering • 関係会社⽀援 Enterprise Technology • コーポレートITグループの課題解決エンジン Boost コーポレートITグループ 丸⼭はここ 3
  2. 理由その1 ID周りの既存課題を解決するのにAzure ADが最適解だったから (HENNGE Access Controlでは限界を感じた) 6 なぜ認証基盤の切り替えが必要だったのか 既存課題 解決策

    各Webサービスでパスワードのセキュリティレベルが統⼀できて いない。 統合できたアカウントについては、 統合認証で指定したパスワードセキュリティが適⽤される セキュリティ監査等により、Webサービスへのログイン履歴を 確認する場合、Webサービス毎に確認する必要がある。 統合認証に対応したサイトについては、ログイン情報が集 約され、Webサービス毎に確認する必要がなくなる。 ユーザーがパスワードを忘れたら、管理者がパスワードリセット するまで当該サイトが利⽤できず、業務停⽌となる。 統合できたアカウントについては、 ユーザー⾃⾝がパスワードを再設定することができる。 現在利⽤しているID/パスワードが、実は既に流出している 可能性があるが、それを確認することはできない。 統合できたアカウントについては、MS社のナレッジにより、 流出しているID/パスワードの利⽤時は通知される。 特権アカウントで厳重なログインの管理ができていない。 (⼀般ユーザーと同じ) 特権アカウントはモバイルデバイスを利⽤した 多要素認証を必須とする等、本⼈確認を厳重にする 〇 〇 〇 〇 〇 〇 〇 〇 〇 統合認証環境を利⽤し、ID/パスワードを統合していく。 (統合認証に対応しているもののみ) PC と各Web サービスで利⽤する ID/パスワード がバラバラになっている。
  3. 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アカウント
  4. 切り替え後の環境 Internet KINTO 社内 外部ネットワーク ※Access Control IP制限、証明書認証 社内 NW

    デバイス Intune 管理 Intune 条件付きアクセス (IP 制限・Intune 準拠チェック) Microsoft 365 認証連携 (SAML) SaaS メール セキュリティシステム
  5. ①アクセスポリシーの再設計 HENNGEで実現していたアクセスポリシーを⾒直す必要があった。 11 切り替えにあたって 考慮事項 HENNGE Accsess Controll アクセスポリシー ①

    デバイス証明書を配布したPCは弊社M365環境へのアクセス可能 ② 指定したIP以外からのアクセスをブロック(IP制限) Azure AD アクセスポリシー ① 多要素認証の強制 ② Intune(MDM)に登録されているデバイスからのみ弊社M365環境アクセス可能 ③ アプリごとのアクセス制限など etc 細かいアカウント種別ごとに細かいルールを設定できるようになった AzureAD 条件付きアクセスへの移⾏
  6. 14 ざっくりスケジュール 1 ⽉ 2 ⽉ 3 ⽉ 4⽉ 会議

    設計 構築・テスト 認証基盤切替 その他 Microsoft 365 設計 運⽤設計 ・ユーザーマニュアル作成 ・管理者マニュアル作成 Azure AD 条件付きアクセス 設定・テスト・有効化 SaaS 認証連携(SSO)検証 ⭐認証基盤 切替 ヘルプデスクメンバーへの 運⽤連携 定例会(隔週) フォロー期間 切替設計 2023年1⽉下旬〜4⽉下旬(3ヶ⽉)
  7. PJ体制はこんな感じ 15 体制 弊社 業務委託 1名 プロジェクトマネージャー 1名 技術責任者 1名

    メンバー 1名 プロジェクト責任者 1名 プロジェクトマネージャー 2名 サポートメンバー 丸⼭ プロジェクト推進担当 計:11名 (6名) ヘルプデスクメンバー 計:3名
  8. ベンダー作業の⼀部を内製化することで、業務委託のコストを削減(20%ほど) ⇨KINTO/KTCは今後も内製化を⽬指していく 超ざっくりやったこと⼀覧 16 ベンダー利⽤について 作業 説明 移⾏設計 HENNGE Access

    ControlからAzure ADに認証を変更するための設計 基本設計 Azure ADの詳細設計を⾏うための基本的な設計 詳細設計 Azure ADの設定を⾏うためのパラメータ設計 設定作業 詳細設計で設計した内容を元に設定 切替作業 HENNGE OneからAzure ADに認証の切替 クラウド連携⽀援 SAMLに対応したクラウドサービスとの連携 問合せ⽀援 Azure AD統合に関するQA対応 ユーザー向け変更点説明資料作成 Azure ADへの統合に伴い既存環境から変更される箇所について ユーザーへの簡易説明資料作成 管理者向け運⽤マニュアル作成 管理者が運⽤で利⽤するマニュアル作成
  9. その1 切り替え前の段階で「⼿順書がわかりにくすぎる!」「こちら側への影響がよくわからない」 との問い合わせを多数いただいてしまった 反省:エンジニア的な視点/切り替え作業者の視点を資料やアナウンス⽂に盛り込み過ぎてしまった。 情報過多。スタッフ⽬線での不安なポイントや簡潔に実施して欲しいことを重視するべきだった。 その2 切り替え後のログインケースの想定が抜けていたことにギリギリで気づく 何かというと… 切り替え後のログイン動作として 「PCを起動してパスワードを⼊⼒してログインする」を想定していた、、が

    「PCを起動してPINを⼊⼒してログインする」というケースが考慮漏れ。 これによって何がまずかったか… 事前のアナウンスで『切り替え後は変更されたパスワードでログインしてください!』を徹底していたため PINの⼊⼒画⾯で⼊ろうとしたスタッフが間違ったものを⼊⼒してしまうというリスクが発⽣してしまった。 ⇨慌てて展開資料の修正とアナウンスを修正 18 切り替え作業周辺のトラブル
  10. 21 まとめ どんなメリットあったか ①PCログオンとAzure ADと連携可能なSaaS製品のログインを統合 ⇨セキュリティレベルを維持したままで、各種SaaSログインを省略 ②セルフサービスパスワードリセットの実装 ⇨ユーザーが⾃分⾃⾝でパスワードをリセット可能になり、IT管理者の負荷低減 ③条件付きアクセスの実装 ⇨柔軟なアクセス許可の設定が可能になりセキュリティの強化

    ex)iP(場所),サインイン頻度,時間,端末…etc で条件を設定できる ④パートナー会社と同じ認証基盤化 ⇨今後の連携のための⼟台作り/効率化/スピードUP ⑤ライセンス費⽤削減 HENNGEライセンス料⾦+デバイス証明書代 ⇨年間約240万円のコストカットに成功 結論 切り替え⾃体は成功 当⽇の問い合わせ0件!といった理想的な状態ではなかったものの スタッフにクリティカルな業務影響は発⽣しなかった。