リスクを分離して削減するために、汎用および共有のユーザーアカウントを使用することは正当化されますか？
さまざまな種類の問題の解決に参加する「サポート」と呼ばれるユーザーのグループがあるとします。各ユーザーはjsmithのような名目上のユーザー名を持っていますが、特権はそれほど多くありませんが、このグループのすべてのユーザーは、オペレーターと管理者の2つの異なるユーザーアカウントを使用しています。アカウントごとに異なる追加の特権があります。管理者には管理者特権があり、オペレーターはさまざまな操作を実行するためにさまざまなシステムにログインできます。
今、私は説明責任を持ち、誰がアクションを実行したかを識別できるようにするために、オペレーターや管理者のような一般的なユーザー名の使用を排除しようとしています。ただし、オペレーターと管理者の特権を各名目アカウントに与えるとセキュリティが向上しますか？ 1つのユーザーアカウントが多くの特権を蓄積するため（日常業務でrootを使用するなど）、セキュリティが低下すると思います。
この説明責任を果たし、分離とセキュリティを維持するにはどうすればよいですか？
ユーザーadm_jsmithとoper_jsmithを作成するのがベストプラクティスですか？ユーザーは、異なるアクションを実行する必要があるたびにユーザー間で変更する必要があるため、使いやすさに影響します。
あなたが正しい、たまにしかそれらを必要としない各ユーザーに権限を与えることは良いオプションではありません。特権アカウントを共有することもできません。
環境を指定しなかったため、2つの回答を提供します。
Linux/* nix
各管理者に、自分の運用アカウントでより高い特権レベルにエスカレートするオプションを与えることができます。通常、Linuxでは、Sudoを使用して特権コマンドを実行します。 sudoersグループ/ファイル（例： https://help.ubuntu.com/community/Sudoers ）に追加することにより、ユーザーにそのような権限を付与します。
ほとんどのLinuxシステムのデフォルトでは、ユーザーがSudoを使用して管理コマンドを実行できるように、ユーザーのパスワードを再度要求するようになっています。ただし、rootアカウントのパスワードを要求することもできます（共有パスワードであるため最善のオプションではありませんが、少なくとも直接のrootログインを許可しない場合は問題ない可能性があります。また、Sudo権限を持つ運用アカウント）。
しかし、より優れた保護が必要な場合は、 https://unix.stackexchange.com/questions/94626/set-Sudo-password-differently-from-login-oneで説明されているように、ユーザーごとに異なるパスワードを要求できます。 。
したがって、Sudoを使用する場合、各ユーザーは（オペレーターとして）ログインするために自分のパスワードを知っている必要があり、必要に応じてパスワードを確認して管理モードにエスカレートする必要があります。保護を強化したい場合は、管理者権限にエスカレートする2番目のパスワード（rootまたはユーザーごとの2番目のパスワード）を要求することもできます。ただし、各ユーザーは独自の（そして1人だけの）ユーザーを持ち、優れたトレーサビリティを備えています。
Windows
各管理者に管理アカウントを与え、管理操作を実行するときにユーザーにパスワードの再入力を要求するようにUACを設定する必要があります。これはLinuxとSudoを使用した場合と同じです。ただし、異なるパスワードを要求するように設定することはできないため、実際に運用アカウントと管理者アカウントを分離したい場合は、管理者ごとに2つのアカウントを使用することが唯一のオプションのように見えます。マイクロソフトのこのガイドをご覧ください。このガイドでは、次のことを正確に推奨しています。 https://technet.Microsoft.com/en-us/library/cc700835.aspx
管理ユーザー用の管理アカウントとユーザーアカウントの分離サービス管理者の役割を満たすユーザーごとに、2つのアカウントを作成します。1つは通常のタスクとデータ管理に使用する通常のユーザーアカウント、もう1つはサービス管理タスクの実行のみに使用するサービス管理アカウントです。 。サービス管理アカウントでは、メールを有効にしたり、Microsoft Officeなどの毎日使用されるアプリケーションを実行したり、インターネットを閲覧したりするために使用しないでください。 2つのアカウントには常に異なるパスワードを指定してください。これらの予防措置により、アカウントが外部にさらされる可能性が減少し、管理アカウントがシステムにログオンする時間が短縮されます。
特定のユーザーとのセッションを作成するログインを作成し、そのユーザーが何らかの追跡Cookieまたはモノを取得することができます。これにより、ユーザーとそのアクションを追跡できます。
通常、これはPlayなどのフレームワークを使用して行います。または春。 Playの例！ ここにありますそしてここに 。プロセスは、異なるフレームワークでも同様です。ユーザーがログインすると、検証され、何らかの追跡可能なIDを取得します。次に、ユーザーのアクションを追跡するログファイルを作成するか、ユーザーが特定のタスクを実行することを許可されているかどうかをIDで確認します。
さまざまな役割についての言葉：
ロールには理由があります。役割を分離して、それぞれの特定の義務に限定することで、追跡可能性とセキュリティに関する問題を減らすことができます。ユーザーは特定のジョブの権限のみを持つ必要があります。これはPOLPとも呼ばれます 最小特権の原則 。
すべてのユーザーが管理者とオペレーターの特権を持っている場合、ユーザーのアクションとセキュリティを追跡することは困難になります。
単純な例は悪意のある同僚かもしれません。彼は重要なデータを単に削除または変更してから、自分の身元を明らかにする可能性のあるすべてのログファイルを消去します。彼は必要なすべての権利を持っているので、これは非常に簡単です。 「通常の」ユーザーと「管理者」がいると、障害が発生します。ユーザーが管理者でない場合は、ログファイルを削除する権限がないため、データを削除できる可能性がありますが、現在は管理者です。彼を追跡することができます。
多分彼らが特定の仕事をするのに必要な権利だけを含むより多くの役割/グループを実装することも同様に役立つでしょうか？
この場合、それはあなたが達成したいことに依存します。
たとえば、rootとしてではなく、日常の活動の制限付きユーザーとして実行される分離の背後にある考え方は、何らかの理由でアカウントが侵害された場合、制限付きユーザーアカウントが持つ権利に損害が及ぶということです。 Seudoationは、Sudoが悪意のある管理者から保護しないのと同じように、悪意のあるユーザーから保護しません！権限が多すぎる悪意のあるユーザーが悪意のあることをしたい場合、そのユーザーは自分のタスクに必要なアカウントに切り替えるだけです。
1つの例は、ユーザーが誤って端末をログインさせたままにして、権限のないユーザーが端末を乗っ取った場合や、不注意なWebサーフィンのために悪意のあるソフトウェアやウイルスが端末にインストールされた場合です。ウイルスまたは許可されていないユーザーは、制限されたユーザーアカウントで実行できることだけを実行できます。
あなたが説明したことに基づいて、私はオペレーターは単なる「グローバルユーザー」であると解釈します。たとえば、通常の「ユーザー」は自分の端末でのみログインできますが、「オペレーター」は「ユーザー」として任意の端末でログインできます。
その場合は、ユーザーにオペレーターの権利を割り当て、管理者アカウントが必要な場合に備えて、何らかの特権の昇格を使用することをお勧めします。たとえば、 "Sudo"またはそれに類似したもの。
トレーサビリティと分離の両方が必要な場合は、ユーザーごとに2つのユーザーアカウントを作成することをお勧めします。 1つは通常の権利を持ち、もう1つは増加した権利を持ちます。オペレーターと管理者の両方のアクセス権を持つユーザーにとって、オペレーターと管理者のアカウントを1つのアカウントに結合することにはリスクがありません。これらのアカウントは、日常の使用ではなく、ハウスキーピングタスクにのみ使用する必要があるためです。
実際には、これらのケースでは、オペレーター/管理者アカウントを個別のアカウントにし、「ユーザー」のようなグループ/共有ユーザーアカウントを持たせるほうがよい場合があります。ユーザーアカウントには特別な権限がないため、誰かが侵害しても問題はありません。
私はさまざまな目的のために複数のオプションがあると思います：
- ユーザーが日常の作業と管理タスクに同じパスワードを使用しないようにしますか（よく使用されるパスワードが盗まれた場合のセキュリティ上の脅威を制限するため）？
- 一部のシステムで「パワーユーザー」を制限し、他のシステムでそれらを有効にしますか？
- ユーザーをよりよく追跡（監査）したいですか？
一般的に言えば、ユーザーが実行するすべての操作を一意のアカウントで追跡および管理することには、簡素化（複雑さが少ないほど、通常は欠陥が少ない）、一貫した管理、および活動の追跡と関連付けの両方で多くの利点があると思います。
つまり、ポイント3では、共有ユーザーを確実に削除します。
ポイント1と2では、ユーザーごとに複数のアカウントを持つことはオプションですが、ポイント3や上記の管理と単純化には最適ではありません。
とにかく、CristianTMが言ったように、Microsoftではこれがベストプラクティスです https://technet.Microsoft.com/en-us/library/cc700835.aspx
Linuxでは、特権のあるアクティビティで要求される別のパスワード（ルートパスワード）が必要になる場合があります（ルートパスワードを一元化することもできます）が、ポイント2だけでは役に立ちません（ユーザーがどのシステムをSudoでき、何ができないかを定義するよりも便利です）。
ただし、私が考えることができる最良の設計は、要塞ホストの概念と認証プロキシに基づいています。基本的に、アイデアは、さまざまな特権サービスにアクセスするためのさまざまな要塞を作成することです。要塞は非常によくあります独立したパスワードで [〜＃〜] otp [〜＃〜]（パスワードよりもはるかに安全）で認証され、そしてサービスそれらはまた、ネットワークの見込み客から分離することもできます。
一部のユーザーに、OTPを介してユーザーを認証する特定のサービスにアクセスするように構成された要塞/プロキシ（少なくとも冗長性のために2つのホスト）へのアクセスを許可することにより、上記の3つのポイントすべてを（専用これらのサーバーでのロギング/監査）。また、Windowsでは、要塞ホストのユーザーの認証がRDPを介して通常のパスワードではなくOTPで実行されるように定義できます。
できるだけ早く共有ユーザーアカウントを削除します。
共有ユーザーアカウントが必要になるのは、1人（または数人）のユーザーしかサポートしていない古いシステムに複数の人がアクセスする必要がある場合のみです。
開発に値する唯一の役割は、ユーザーと管理者の役割（そしておそらくいくつかの管理者の役割）になるでしょう。
ユーザーの役割は非常に制限されている可能性が高く、ワークステーションへのログオン、職務の実行などに適しています。一般的なユーザー集団にとって最低限必要なものを見つけ、その役割を作成する必要があります。
オペレーターの役割は、その役割が正確に何であるかは不明ですが、説明に従って複数の異なる「操作」を実行するために複数のシステムにログインするために使用されます。すべてのオペレーターがこれらすべてのシステムに接続していますか？それらのうちのいくつかはいくつかにのみ接続し、他はいくつかの他に接続し、一部はすべてに接続しますか？誰が何に接続するかが異なる場合は、役割を廃止し、ケースバイケースでユーザーを承認して（最小特権の原則）、ユーザーがシステムやリソースへの不要または無許可のアクセスを取得しないようにします。これにより、セキュリティが強化されます。
管理者アカウントは、管理する必要があるシステム（またはシステムのグループ）に固有のいくつかのグループ/役割に分割する必要があります。また、主に管理業務のみに焦点を当てるべきです。 Windows AD環境の場合、リモートログオンを無効にすると、ユーザーは通常のユーザーアカウントを使用してリモートシステムに接続し（ "operator"アカウントの情報から生成されたアクセス許可を使用）、管理者アカウント（jsmith_aなど）を使用します。 UACの昇格。管理グループは、この_aアカウントと、ユーザーが管理することを許可されているシステムのグループ/役割のみに付与する必要があります。これは、侵害された管理者アカウントが複数のシステムにリモートで使用されるのを防ぐという二重の効果があり、単一の侵害されたユーザーアカウントが管理上の変更を行うことも防ぎます。
これは間違いなく「オペレーターと管理者」のための「紙の証跡」を作成し、環境の説明責任のレベルを高めます。また、ユーザーアカウントのパスワードが期限切れになるよりも頻繁に、管理者アカウント（_a）のパスワードを期限切れにすることを検討してください。長いパスワード履歴と1〜3日のパスワードの最短有効期間は、最も専用のパスワードローテーターでさえパスワードが循環しないようにするのに十分です;）（それがログに表示されないわけではありません。。。）
帽子は始めるのに良い場所です。