はじめに
株式会社ONE COMPATHのmikoです。インフラの設計・運用に携わっています。
本記事では、開発環境、本番環境(以下、各環境)における特権ID管理ソリューションとして、NRI社が提供しているSecureCube Access Check(以下、Access Check)の全社展開事例をご紹介します。
※特権IDとは、root、Administratorといったシステム内で最も強い権限を持つID(ユーザー)を指します
Access Check製品紹介ページ
https://www.nri-secure.co.jp/service/solution/accesscheck
背景
従来の特権ID管理は、各環境によりAccess Checkと別の管理ツールに分かれており煩雑な点が問題でした。
統一されたインターフェースでのログ確認やユーザー管理が可能なAccess Checkであれば、複数ツールを扱う場合と比べて管理工数を削減できると判断し、Access Checkへの全社展開を進めることとしました。
現状把握と移行に向けたヒアリング
Access Checkへのスムーズな全社展開と従来の利用者体験の低下を防ぐことを目的として、旧管理ツールの利用実態把握と主要利用者へのヒアリングを並行して実施しました。
ヒアリングでは、
「サーバからローカルへのファイル転送は引き続き可能か」
「従来の機能が使えなくなる部分はないか」
といった具体的な懸念が挙がりました。
これらの懸念点に対し、Access Checkの機能では問題がないことは確認できましたが、実際の操作感や使い勝手については、環境構築後の動作検証フェーズで集中的に確認するという方針としました。
また、この事前のヒアリングを通じて、マニュアルで重点的に説明すべき箇所や、移行時にサポートが必要なポイントを事前に特定できたことが、その後のスムーズな移行につながりました。
環境構築
AWS上にAccess Check専用アカウントを用意し、可用性とログ管理を重視した構成で環境を構築しました。
可用性の確保
Access Checkは開発メンバー、インフラメンバーなど多くの利用者が日常的に利用するため、
EC2インスタンスの入れ替え(メンテナンスやデプロイ、障害復旧時)における影響を最小化する必要がありました。
そのため、NLBを配置することで、DNSキャッシュの影響を受けずにスムーズなインスタンス切り替えを可能にする構成としました。
監査対応を見据えたログ管理
特権ID管理ソリューションを全社展開するにあたり、セキュリティ監査や内部統制の要件を満たす必要がありました。
この要件に対応するため、Access Check サーバ内に限定せず、耐久性とセキュリティに優れたAWS S3へログを定期的にバックアップする仕組みを構築しました。
Access Checkサーバ自体のセットアップは、充実したセットアップガイドにより、大きな問題なく完了しました。
環境構築後の全社展開
多くの利用者の各環境へのログイン方法が大幅に変わる構成変更であり、全社展開時のリスクを最小化するため、以下の流れで段階的に進めました。
- Access Checkへの権限やポリシーの設定
- 動作検証
- 各種ドキュメントの整備
- プレ利用の開始
- 全社利用の開始
- 旧管理ツールの利用停止
プレ利用期間では、全社展開前に利用者が抱くであろう疑問を解消することを目的とし、先行ユーザーからフィードバックを収集してドキュメントの質を向上させました。
また、利用者全員が安心して移行を進められるように、一定期間、旧ツールとの並行運用を設けたことで、万一のトラブル発生時には旧環境へ即座に切り戻せるというリスクヘッジを確保し、移行を確実なものとしました。
全社展開による効果
全社展開により、以下の効果を得られました。
- ユーザー・権限管理の統一化: 各環境で個別に実施していた管理作業をAccess Checkに一元化し、管理工数を削減できました
- ログ確認の効率化: Access Check管理画面から全環境のアクセスログ・操作ログを統合的に確認できるようになり、インシデント対応やセキュリティ監査時の調査工数も削減できました
- 属人性の解消と対応体制の強化: ツールが統一されたことで、インフラチーム全員が対応可能となり、特定メンバーへの依存を解消できました
おわりに
Access Checkの全社展開により、特権ID管理の統一と運用負荷の軽減を実現できました。
技術的には既存環境の横展開でしたが、多くの利用者に影響する変更だったため、移行には不安もありました。ただ、事前のヒアリングとプレ利用期間を設けるなど、利用者とのコミュニケーションを意識したことが、大きな混乱なく移行を完了できた一因だと感じています。
