BeyondTrust社Blog “How to Manage and Secure Service Accounts: Best Practices” February 25, 2021 by Alex Leemonより
サービスアカウントは、アプリケーションを実行し、自動化されたサービス、仮想マシン・インスタンス、その他のプロセスを実行するのに使われる特別な種類の非ユーザー用特権アカウントです。サービスアカウントは特権を持つローカルアカウントやドメインアカウントを使用することができ、場合によってはドメイン管理者権限を持たせることもできます。このように高度な特権によって、多くのITワークフローを円滑に進めることができますが、一つのサービスアカウントが多くのアプリケーションやプロセスで簡単に参照することができるようにもなってしまいます。この相関性に加えて重要な使途で利用されるという性質があるため、管理が非常に難しくなっています。
このブログ記事では、サービスアカウントの使い方、異なる環境での共通のユースケースとアカウントタイプ、サービスアカウントの管理における課題、サービスアカウントの管理と保護に関するベストプラクティスとソリューションについて考察します。
サービスアカウントの使い方
サービスアカウントは自動化されたサービスプロセスを実行し、人間ではなくアプリケーションによって使用されます。サービス、タスク、COMオブジェクト、インターネット情報サービス（IIS）、SharePoint、データベース、アプリケーションに設定することができます。一つのサービスまたはプロセスのアカウントを複数の場所で参照することができます。
多くのサーバでは、LinuxにおけるrootやWindowsにおけるadministratorのようにローカルアカウントを使って、誰かがマシンにログインしているか否かに拘わらず、永続的にアプリケーションを実行しています。たとえば、あるウェブサイトが永続的なアプリケーションの一例になることも、データベースや他の一連の業務アプリケーションの一例になることもあります。
サービスアカウントがこうした永続的なアプリケーションに必要なのは、アプリケーションのユーザに代わって動作を実行できるようにするためです。つまりサービスアカウントは、重要なデータやシステムへのアクセス手段を持たないユーザが限定的な動作を実行するためのプロキシなのです。
多くの場合、サービスアカウントの仕組みとして、あるアカウントはアプリケーションだけでなく、そのアプリケーションがやり取りするあらゆるものに対して知られ、確認できるものにしておかねばなりません。結果的に、そのサービスアカウントは通常、強力なアクセス資格情報となります。
一般的に、サービスアカウントはサービスソフトウェアのインストールの際にパッケージマネージャーによって作成され、構成されます。ですから、たとえ管理者であっても、人間は直接サービスアカウントを作成する作業に関与しない（してはならない）のです。
Windows、Unix、Linux、クラウドでのサービスアカウントの例
サービスアカウントの名前はシステムによって違います。例を挙げましょう。
UNIXとLinux：サービスアカウントはinitまたはinetdで、アプリケーションを実行することができます。
クラウド：サービスアカウントはクラウドサービスアカウント、クラウドコンピューティングサービスアカウント、または仮想サービスアカウントと呼ばれます。
Microsoftはあるサービスアカウントを「具体的にWindowsサーバのオペレーティングシステムで動作しているサービスのためのセキュリティコンテキストとなるように作られたユーザアカウント。ローカルとネットワークのリソースにそのサービスがアクセスできるかどうかは、セキュリティのコンテキストで決まる」と定義しています。このようなサービスアカウントの多くは、昇格された特権を持つ基幹業務のアプリケーションに接続します。
Windows：サービスアカウントは、下記のような最も一般的なタイプのものが知られています。
- LocalSystem
- NetworkService
- ローカルユーザアカウント
- ドメインユーザアカウント
サービスアカウントの管理と保護の課題
正しくシステムを機能させ事業を継続させられるかどうかは、基本となるサービスの機能にかかっています。あるサービスアカウントが侵入を受けていたり不具合を起こしていたりすれば、広い範囲でシステム障害が起こる可能性があり、特に、アカウントが複数のサービスにひもづけられている場合はその危険が高くなります。
パスワードの課題：サービスアカウントの構成上、スーパーユーザ資格情報のパスワード変更は、認証システム（すなわちActive Directory）で行うだけでなく、その同じ情報に関してパスワードを保管しているすべてのサービスまたはアプリケーションで行わねばならないことになります。ですから、認証コードだけでなくすべてのリファレンスも更新しなければなりません。サービスアカウントが保管されているすべての場所を更新することは一般的に「更新伝播」として知られています。
一つでもパスワードが保管されている場所のどれかを見逃してしまうと、その誤ったパスワードが使われ、雪崩のように一気にシステム障害が発生します。あるサービスで不正なパスワードが使われると、オペレーティングシステムは、アカウントが攻撃されているとみなし、そのアカウントを拒否することにもなりかねません。そうすると、今度はその拒否されたアカウントを使っているすべてのサービスに障害が発生するのです。
正しく同期されていないパスワードが関与してくるため、多くの組織は障害の危険に目をつぶり、この問題を単に無視する方を選んでいます。その結果、サービスアカウントは何年も変更されないままの無期限の資格情報で構成されていることが多くなっているのです。
アクセスの課題：サービスアカウントにはローカルシステムでの特権アクセス権があり、システム外のリソースへのアクセス権（すなわちWindowsのドメインアカウント）を持っている場合もあるのです。サービスアカウントがドメイン管理者レベルの権利を必要とすることはめったにないのに、予測不能な操作上の問題が発生してサービスの持続性に悪影響がある場合に備えて、過剰な特権を安易に与えられていることが多いのです。
管理上の課題：サービスアカウントは特定の人間に直接ひもづけられているわけではないので、サービスアカウントのアクセスには、そうしたアカウントのための資格情報の共有が必要です。こうして資格情報を共有することで、信頼性が損なわれ、サービスアカウントの監視が難しくなります。たとえば、あるサービスアカウントにひもづけられている資産やシステムが必要なくなっても、サービスアカウントが放置されていることが多いのは、誰もそれに直接責任を負っていないからです。同様に、ソフトウェアのインストールや保守によく使われる一時的なサービスアカウントも、最初に使われた後は長く放置され、デフォルトのパスワードをつけたままのことも非常によくあります。
サービスアカウントを中央でプロビジョニングすることは、こうしたアカウントの起源がそれぞれ異なる（Windows、Unix、Linux、クラウドは、それぞれが管理するソフトウェアがインストールされる際に個別にプロビジョニングされた別のアカウントを持っている）ため、かねてから課題になっていました。結果として、多くの機関は手作業でサービスアカウントのプロビジョニングを行っています。
サービスアカウント管理にまつわる複雑さに鑑みて、サービスアカウントの資格情報を手作業で管理するという手法を取るITチームもあります。これは煩雑で誤りが発生しやすく、致命的な障害を招きかねない作業です。手作業での管理には、資格情報が存在するすべての場所を確認し、その情報が使われるたびに変更を実行する必要があります。先に述べたように、資格情報を間違えるとサービスを混乱に陥れ、基幹システムに障害を生じるかもしれません。さらに、ほかのパスワード管理の事例と同様に、人間というのは決まって、覚えやすい資格情報を使ったり、複数のアカウントで資格情報を使いまわすという罠に陥るものです。資格情報が使いまわされると、ある件で起きた悪用の事例が、同じパスワードを共有しているすべてのアカウントでの悪用につながってしまう可能性があります。
可視性と監査の課題：サービスアカウントは、あらゆるタイプのマシンまたは非人的アカウントに共通の可視性の問題を生じさせます。こうしたアカウントは通常、人手を介さずにバックグラウンドで実行されるので、サービスが順調に運用されているように見える場合は、監視や監督をすり抜けることがあるのです。さらに、たいていの組織は忘れられたり使われなくなったりした迷子のアカウントを含め、膨大な数のサービスアカウントに悩まされています。複数の身元証明（ユーザ）が一つのサービスアカウントにアクセスし、同じログイン情報を共有していることもあり得ます。つまり、一つのユーザの動作をそのサービスアカウントへの変更に結びつけることが不可能な場合もあるということです。
簡単に言えば、サービスの資格情報のプロビジョニング、登録、セキュリティベストプラクティスの強制実施、セッション監査、プロビジョニング解除などの処理ということになると、ほとんどの組織には、サービスアカウントの生涯にわたる管理の上で深刻な欠陥があるのです。
サービスアカウントの管理に関する課題は、なぜアカウントがハッカーに狙われる対象となるのかという問題も内包しています。
有効なサービスアカウント管理のベストプラクティス
サービスアカウントは慎重に管理・統制・監査する必要があります。ほとんどの場合、そうしたアカウントは所有者としての身元証明にさかのぼってひもづけることができます。ただし、サービスアカウントにはシステムにログオンする人と同じ特徴を持たせてはいけません。双方向のユーザインタフェース特権も、通常のアカウントまたはユーザとして操作できる権利も与えてはならないのです。オペレーティングシステムやインフラストラクチャによっては、バッチ処理の実行からアカウントに適切なシェルを割り当てないことに至るまで、すべてを規制することになることもあります。また、どのような形式であってもジャストインタイム（JIT）のアクセスモデルにサービスアカウントを移譲することはできません。
このサービス管理問題を解決するための最も効果的で安全な方法は何でしょうか。最良の方法は二段階方式です。第一段階は、すべてのアカウントの特定と一元管理をただちに計画することです。第二段階は、新しいアカウントの自動化された登録と管理に基づいた継続的なプログラムの実装です。
第一段階：すべてのアカウントを特定し、一元管理下に置く
自動化によってすべてのサービスアカウントを発見し登録する
すべての特権サービスアカウントがどこにあるかわからなければ、その利用状況を完全に管理したり監査したりすることはできません。他の種類のすべてのアカウントと同様、最優先事項は、継続的な識別と一覧作成を行い、すべてを一元管理できるようにする方法を導入することです。
BeyondTrustのソリューションなら、ネットワーク全体であるサービスアカウントが参照されているすべての場所を発見することができます。識別と分類がすむと、このソリューションは、シンプルですぐ使える構成によって、アカウントを自動的に管理下に置き、それによって組織がアカウントの登録を迅速に行ってリスクを軽減できるようにすることができるのです。
サービスアカウントの分析
このデータは、発見の手順で見つかったサービスアカウントの総数を示したものです。一つのサービスアカウントは、個々のエンドユーザではなく、アプリケーションまたはサービスに属する特殊なタイプのアカウントです。
検知レポート：サービスアカウント分析結果
検知レポート：サービスアカウント・スキャンサマリー
*以下訳注
| サービスアカウント | 15 |
| サービス総数 | 89 |
| IIS App Pool | 76 |
| DCOMコンポーネント | 11 |
| COM+ アプリケーション | 0 |
| スケジュールされたタスク | 1 |
| Windowsサービス | 1 |
| 無期限パスワードを持つアカウント | 3 |
| パスワード日数が30日未満の無期限アカウント | 2 |
| パスワード日数が30～90日の無期限アカウント | 1 |
第二段階：新しいアカウントの自動登録と管理
新しいサービスアカウントの登録を自動化する
IT環境の流動的な性質を踏まえ、自動発見機能を使って時間を節約し、管理されないまま放置されるアカウントがないようにします。アカウントを自動的に識別して分類すれば、新しいサービスアカウントがただちに管理下に置かれ、手作業での管理の煩雑さもリスクもなくなります。これによってある環境にあるすべての特権を完全に見ることができます。BeyondTrustの特権パスワード管理ソリューション、Password Safeは、Smart Rulesを使って継続的に新しいアカウントを管理下に置くことができます。この製品は、組織が一元管理を使ったサービスアカウントの制御と完全な監査証跡の管理を行うのに役立ちます。
サービスアカウントへのアクセスを保護し、監視する
サービスアカウントにひもづけられている特権の資格情報（パスワード、SSH鍵）は、暗号化された資格情報保管庫で一元保護されていなければなりません。悪用の危険をなくすためには、こうした資格情報へのアクセスを制御し監視しなければなりません。
Password Safeは、特権の資格情報と特権セッションの管理を自動化し、サービスアカウントなどすべての特権アカウントへの安全なアクセス制御、監査、警告、記録を実現します。
資格情報を有効に伝播する
サービスアカウントの資格情報が変更されたとき、それを参照されているあらゆる場所へ自動的に伝播することが、システム障害や実行停止を防ぐための重要な条件です。
Password Safeは、資格情報の変更を実行するたびに、サービスアカウントのパスワード変更前にその一覧表を都度発見することができます。この製品はまた、資格情報の同期が外れてアプリケーションに不具合が起きるのを防げるスピードと正確さで、資格情報を伝えることもできます。
サービスアカウントのプロビジョニングに関するその他のベストプラクティス
最小権限の原則（PoIP）の適用：サービスアカウントを作成する際に、対象となるタスクを完了するのに必要な最小限の特権でアカウントを作成することをお勧めします。たとえば、一般に外せる追加の特権として、リモートアクセス機能、インターネットと電子メールのアクセス、リモート制御権などがあります。アクセス制御のリスト（ACL）を使えば、資産へのリソースを定義することができます。この処理の一環として、あるサービスアカウントがアクセスできるすべてのリソースを特定し、このアクセスが適切であるかを判断し、必要な変更を行って最小特権が強制的に実施されるようにすることが必要です。また、最小特権については、ある身元証明に関連するサービスアカウントの数を最小現に保つよう努めることも必要です。
サービスアカウントを組みこみ式の特権グループに入れるのを避ける：ローカル管理者またはドメイン管理者のグループなど、組み込み式の特権グループでサービスアカウントを割り当てるのには危険が伴います。このグループのユーザがすべてサービスアカウントの資格情報を知ることになり、こうした資格情報が誤って使われたり悪用されたりすることもあるからです。
サービスアカウントのための非常用手段を設けておく：ネットワークの停止やアプリケーションの故障、天災などの理由により、組織が基幹システムへの安全なアクセスを再構築しなければならない場合があります。使っているサービスアカウントのパスワード管理ソリューションが使えなくなるような障害が発生する場合に備えた計画が必要です。このような場合、サービスアカウントのパスワードがわからずサービスを再開することができなければ、次のような問題解決の手段を講じてサービスを再開してみてください。
- 機能別アカウントを使ってサービスのパスワードを任意抽出する
- 保存されている資格情報を使ってシステムへの特権接続を構築し、手作業でサービスアカウントのパスワードを設定してからパスワード管理を自動化する
非常時の際の特権資格情報へのアクセスに関する詳細は、この白書をご参照ください。
サービスアカウントの保護と管理のためのソリューション
ほぼすべてのITシステムにとって、円滑な稼働のためにはサービスアカウントが欠かせません。こうした重要なアカウントを手作業で管理するだけでは、最新の企業のセキュリティと監査の要件を満たすことはできません。
今、組織はソリューションを利用してサービスアカウントの発見と管理を自動化する一方で、それに対するアクセスを保護し、制御し、監査することができます。サービスアカウントの増殖の危険をなくし、特権の資格情報への侵入の危険から企業を守るためには自動化が欠かせないのです。
BeyondTrustのと特権パスワード管理ソリューション、Password Safeは、特権パスワードとセッション管理を組み合わせて、特権の資格情報を使ったすべての動作を発見、管理、監査することができます。BeyondTrustの製品があれば、特権ユーザアカウントやサービスアカウント、アプリケーションその他を簡単に制御し、コンプライアンスや調査解析のために検索可能な監査証跡も行うことができるのです。
関連資料
Download BeyondTrust’s FREE Discovery Tool
Privileged Password Management Explained (ホワイトペーパー)
How to Access Privileged Passwords in ‘Break Glass’ Scenarios (ホワイトペーパー)
Functional Accounts: Do’s & Don’ts (ブログ)
Alex LeemonはBeyondTrustの製品マーケティング部長として、特権パスワードとセッションの管理および脆弱性管理ソリューション特化した業務を行っています。企業規模の基幹インフラ組織における安全性とセキュリティの課題を解決する業務で15年の経験を持ち、BeyondTrust入社前には、産業用の制御製品と産業用のモノのインターネット（IIoT）の開発に関連した様々な業務に携わってきました。