5.3 さまざまなアカウントの管理
5.3.1 アカウント管理とMS Active Directory
ユーザーやコンピューターリソースの管理基盤として、多くの組織ではMicrosoft Active Directory（AD、アクティブディレクトリ）を利用することが多くなってきました。このシステムは従業員のユーザーとコンピュータ、各社内システム・リソースへのアクセス権限まで、ITインフラを運用管理する中枢であり、情報システム部門がアカウント管理に重要な役割を果たしています。最近はクラウドベースの認証とアクセス制御の仕組みにである、Microsoft Entra ID（旧Azure AD）が利用されることが多いようです。
ADの機能は多岐にわたりますのでここでは簡単に紹介するのにとどめます。ディレクトリとはここでは「一覧表」のようなものであり、ADは組織の人や機器といったリソースを階層的に管理するディレクトリです。
ADでは、ドメインという領域が作成されます。この中で、ユーザーやコンピュータ、それらのグループを扱う仕組みになっています。ドメインコントローラー（DC）と呼ばれる管理システムによって、シングルサインオンなどの機能が使えるようになります。
管理者側でセキュリティポリシーも設定できるようになっているので、端末が更新されていなかったり、設定ミスによって脆弱な状態になったりしないよう設定を強制することもできます。
大きな組織になると、多数のドメインを作成して階層構造を作ったり、互いにアクセスできるような信頼関係を作ったりして運用することもあります。
ADなどのディレクトリサービスは組織のアカウントを包括的に管理することができるため、攻撃者からすると最も攻撃したい標的といえます。そのため、ADのハードニングやセキュリティ対策は、他のシステム以上に優先的に実施すべきと考えられています。弊社でも、ITシステム全体のセキュリティ対策を実施したいが、予算の制約があるなどの話が出た際は、まずADのセキュリティ対策を提案することが良くあります。
5.3.2 管理者アカウントと特権ID管理について
管理者アカウントはサーバーやOS、データベースなどのITシステムを操作する中でも権限が高いアカウントになります。システム自体の起動や停止、マスターデータの変更や機密データへアクセスができたりできるものですから、万一漏えいした際には大きな問題に発展しかねません。たとえば、ランサムウェアの感染を組織内へ展開させて大きな被害を与えることも可能になります。そのほか、内部不正や誤用にもつながりますので、慎重に取り扱う必要があります。
管理者アカウントにおける運用の基本は、まず誰かのアカウントに大きな権限を与えるのではなく、管理系の作業用に独立したアカウントを作っておくことです。管理者は、必要に応じて、組織のメンバーとしてのアカウントと、管理用のアカウントを使い分けることになります。
管理者の権限をさらに安全に使用したい場合は、管理者権限を利用者が必要な時だけ貸し出したり、利用したらその記録を取っておいたりすることを検討します。こうした管理を目的としたツールは「特権ID管理ツール」などと呼ばれます。特権とは、ここでは管理者アカウントと同じレベルの権限のことです。
こうしたツールは国内や海外のデータセンターへのアクセスに加えて、AWSやAzureなどのクラウドサービスのアカウントの管理などで使われています。高い権限を持つアカウントをいつ、誰が使ったのかを記録したり、そのアカウントの貸し出しを承認フローにのせて許可を出したりできるようになっています（図2）。
このような機能はADだけでは利用できないので、別個のソリューションを導入することになりますが、たいていはADや他のディレクトリサービスとの連携を前提に設計されています。
5.3.3 サービスアカウントの管理
サービスアカウントは、人（ユーザー）ではなく、アプリケーションやコンピュータの特殊な作業で使用されるアカウントです。たとえばスケジュール化されたタスク、プロセスの動作、自動化のために利用されます。コンピュータは人間が操作するだけでなく、一定の時刻になったら何か作業をするなど、人間が介入しない形でも動作してほしい場合があります。サービスアカウントはこうした特定の目的を実行するために使われます。
サービスアカウントは、よく攻撃のターゲットになりやすいと言われますが、その理由は複数あります。まずサービスを中断することなく適切に機能するためには、サービスアカウントは管理者権限ほどではないにしても、何らかの特別な権限を必要します。
その権限を設定する場合、最小権限の原則を意識して設定されていればいいのですが、面倒なので管理者アカウントと同じグループに追加されることもよくあります。そうなると、攻撃者はサービスアカウントを悪用して、マルウェアをパソコンやサーバーへ自由にインストールしたり、環境全体を探索したりできますし、アカウントやデータを削除することもできます。
サービスアカウントは理想的には、定義済みの役割ベースのアクセス制御（RBAC）や権限委任モデルといったサービスアカウントを管理するためのベストプラクティスがあるのですが、それらがいつも活用されているとは限りません。そもそも管理されていない場合もよくあり、どのようなサービスアカウントがあるのか、組織が把握できていないケースも珍しくないのです。
たとえ管理されていても、サービスアカウントは人間がいつも利用してわけではないので、悪用されていても気が付きにくいということもあります。また、サービスアカウントの中にはパスワードローテーションや二要素認証などが設定できない場合もあります。
サービスアカウントは管理者アカウントと同様、ADなどのツールを利用して管理するのが良いでしょう。しかし管理者アカウントと異なり、サービスアカウントは各部門の関係者が作る場合もありますので、その管理
下に置かれないような（いわゆる野良の）アカウントができてしまうこともよくあります。そのため、ツールだけでなく、作成者が台帳を作り、アカウントの目的、関係者（責任者）、定期的な棚卸の実施とその記録などを記載しておくべきでしょう。
