PCI-DSSパスワードガイダンスはサービスアカウントに適用されますか？

Question

サービスアカウントは、アプリケーションの実行のみを目的として作成されたユーザーアカウントです。たとえば、オンラインバンキングのWebサイトには、コードが実行される単一のサービスアカウントがある場合があります。

他のアカウントと同様に、サービスアカウントにはパスワードがあります。これらは、2つの重要な点でエンドユーザーアカウントのパスワードと異なります。

パスワードは私たちによって生成されます（そしてそれらは大きくてランダムです）
パスワードは Windowsに保存されていますなので、人の介入なしで必要なときにサービスを開始できます。

私はこれらのアカウントに立ち向かわなければならないパスワード管理プロセスの種類を理解しようとしています。

PCI-DSS ガイダンスは、パスワードに関する次の一般的なガイダンスを設定します。

すべてのユーザーにシステムコンポーネントまたはカード会員データへのアクセスを許可する前に、一意のIDを割り当てます。
ユーザーID、資格情報、およびその他の識別子オブジェクトの追加、削除、および変更を制御します。
終了したユーザーのアクセスを即座に取り消します。
90日以内に非アクティブなユーザーアカウントを削除/無効にします。
6回以下の試行後にユーザーIDをロックアウトすることにより、繰り返されるアクセス試行を制限します。
ロックアウト期間を最低30分に設定するか、管理者がユーザーIDを有効にするまで。
セッションが15分以上アイドル状態であった場合は、端末またはセッションを再度アクティブにするために、ユーザーに再認証を要求します。
ユーザーのパスワード/パスフレーズを少なくとも90日ごとに変更する

ただし、これらのルールの一部は、サービスアカウントには意味がありません。たとえば、多分ロックアウトを強制しても意味がありません。たとえば、同じIDを一連のマイクロサービスに使用する場合、90日ごとにパスワードを変更するのは大変なことです。

これらのルールのいずれかがサービスアカウントに適用されますか、それともエンドユーザーアカウントにのみ適用されますか？ルールがエンドユーザーアカウント専用である場合、サービスアカウントにはどのようなルールが存在しますか（存在する場合）？

（「適用」とは、「PCI監査中に考慮される」ことを意味します）

grimthaw · Answer

「ガイダンス」という言葉の使用は外れています。

標準では、要件ごとに4つの部分があります。

要件8.2.4の状態：

ユーザーのパスワード/パスフレーズを少なくとも90日ごとに変更します。

対応するテスト手順があります。

サンプルの各項目について、ユーザーがパスワード/パスフレーズを少なくとも90日ごとに変更することを要求するようにユーザーパスワード/パスフレーズパラメーターが設定されていることをシステム構成設定がどのように確認したかを説明してください。

ただし、そのガイダンスは、要件の背後にある意図を提供します。

変更なしで長期間有効なパスワード/パスフレーズは、悪意のある個人がパスワード/フレーズの解読に取り組む時間をより多く提供します。

したがって、90日ごとにパスワードを変更せずに（制御ワークシートを補正することによって）パスワードを変更せずに意図（ガイダンス）を渡すことができることを示すことができる場合、たとえば、使用時間内にハッシュを解読できないほど複雑なパスワードを使用する、追加のロギング（要件を超える）など。QSAは、要件が意図を満たしていると言う場合があります。

サービスアカウントの「 Admin 」アカウントとしてカウントされるもののいくつかの定義（ただし、「標準」は、PCIおよびQSAの意志ですべてのFAQおよび「ガイダンス」ドキュメントを上書きします）。

DoubleD · Answer

実際の答えは、監査時にQSAが言うことです。

質問する公式チャンネルがある場合は、それらを使用してください。可能であれば、書面で回答を得てください。

自動コンプライアンスが最善のルートです。手動による対策が増えると、人為的エラーの可能性も高まります。

以前の雇用主では、コンプライアンスの問題について非常にリスクを嫌っていました。この場合、サービスアカウントは他のユーザーアカウントと同様に扱いました。

小さなフットプリントを超えるものがあれば、自動化は多少必要です。これらの要件を満たすためにいくつかのアプローチを検討しました。

つのオプション

Windowsでは、グループ管理サービスアカウント（GMSA）を使用する場合、技術的にはユーザーアカウントではなくマシンアカウントであり、パスワードの変更は自動的に処理されます。 Windowsドメインがある場合は無料ですが、2012レベル以上である必要があります。

パスワードの変更、保存、検証などを行う、Secret Serverなどのアプリケーションを使用できます。 GMSAとは異なり、テストやトラブルシューティングを行う必要がある場合、管理者は手動で認証できます。環境によっては、プラスになる可能性もあります。ただし、考慮すべきライセンス料があり、さらにそれは管理する別のアプリケーション/データベースです。

スクリプトを使用してパスワードを変更し、サービス構成を更新します。 PowerShellを使用してアカウントのパスワードを変更し、Set-Serviceコマンドレットを使用してその変更をデバイスにプッシュできます。これには事前に費用はかかりませんが、スクリプトを作成して保守する必要があるため、GMSAよりも労働集約的です。