共有ユーザーアカウントを使用しないのはなぜですか？
共有ユーザーアカウントを許可しないことのベストプラクティスを知っていますが、このベストプラクティスはどこに定義されていますか？ ISO規格か何かですか？常に個人アカウントを作成する理由は何ですか？
アリスとイブはボブのために働きます。アリスはボブが彼女にするように頼んだことを正確に行う非常に良い労働者です。 Eveは、Bobの会社を破壊することについて地獄のような犯罪の首謀者です。
アリスとイブの両方が同じアカウントを共有しています。
Eveはアカウントにログインし、それを使用して重要なビジネスプロセスを妨害します。監査ログはこのアクションをキャプチャします。
ボブは誰が自分の会社を妨害したのかをどうやって知るのですか？彼は悪い俳優を取り除かなければならないが、彼の会社は彼らが行う仕事に依存しているので、両方を解雇することはできません。彼は1人だけを発砲することができましたが、彼はどちらが彼の友人でどれが彼の敵であるかを知る方法がありません。
アリスとイブが別々のアカウントを持っている場合、ボブはイブが妨害行為をした人物であると確信できます。 Eveは、自分のアカウントが監査され、彼女が逮捕されることを知っている場合、妨害行為を避けることさえあるかもしれません。
編集：コメントから追加：
イブが辞任した場合、個人アカウントを無効にするだけでなく、アクセスできるすべてのアカウントのパスワードをリセットする必要があります。これははるかに管理が難しく、あなたはwillアカウントを逃します。
さらに、アクセスをきめ細かく制御する機能がなくなります。アリスが小切手を作成し、イブがそれらに署名する必要がある場合、それらが同じアカウントを共有する場合、それを強制する技術的な方法は基本的にありません。
また、特定の個人が環境への悪意のある変更に気づくことを難しくします。アリスはアリスのデスクトップ上にあるファイルを知っています。新しいファイルがあると、おそらく彼女に赤信号が発生します。アリスは、アリスとイブの共有デスクトップにあるファイルを知りません。新しいファイルは、悪意のある俳優ではなく、肩をすくめて、別のユーザーがそこに置いたという仮定で満たされる可能性があります。
友人の職場で起こった実話（管轄：ドイツ）：
彼女の会社の電子メールを介して彼の失礼な侮辱のクライアントの同僚。彼女はこれのために解雇されました。彼女は法廷に行きました。そこで彼女の弁護士は、従業員が自分のパスワードを共有したことを裁判所に知らせました（たとえば、特定の同僚が不在のときにクライアントのメールに答えるために）。
裁判官は、問題の人が本当に侮辱的な電子メールを送信した人であるという良い証拠はないと判断しました。その人は再雇用され、失われた賃金を補償されなければなりませんでした。
士気：ユーザーアカウントの1つの機能は、ユーザーを相互に識別して、アクションを監査可能にすることです。プライベートアカウントだけがその機能を果たします。
すべてのコンテキスト（上部にセキュリティ）で個別のアカウントを使用する必要があります。
Adonalsiumの例は、必須であるため示しています。 「不可能」または「役に立たない」というまれな状況があります...
例：「不可能」（レガシープロトコル/アプリケーション）「関連なし」（匿名のアクション）
それが不可能な場合でも、特定する必要がある場合は、可能な限りソース情報（接続情報、接続時間など）を追加するリスクを軽減する必要があります。
ISO 27001リスク評価方法論、ISO 31000リスク管理をチェックして、「共有ユーザーアカウントを使用しない理由」という質問への回答の出発点として使用できます。
一般的な答えは、説明責任、トレーサビリティなどです。つまり、正確に誰が何をしたのかを知ることができます。
共有アカウントには、n人が何かをしている可能性がありますが、あなたが持っているすべてのことが、そのことをしている1つのアカウントを指しています。
この問題は通常、誰かがこのアカウントのアクティビティに対して法的に責任があることを確認することで解消されます。これは可能かもしれませんし、可能でないかもしれません、そしてあなたには他人の行動に対して責任を負う人がいないかもしれません。
この問題は、いくつかの監視アクティビティを外部委託するときによく発生します-監視タスクを実行するアカウントは、そのアクションを担当するその会社を契約上担当する必要があります。
責任者を割り当てることができない場合、リスクに基づいて決定を下すのは経営者次第です。つまり、サービスを持たないか、そのアカウントで誰が何をするかを知らないということです。
ベストプラクティスはどこにも「定義」されていません。それが用語の意味です。ベストプラクティスは、ほとんどの人が最良の方法だと考えることを行う確立された方法です。
それは逆になります。 「ベストプラクティス」が優勢になると、通常、標準化委員会の誰かがそれを何らかのISOまたはその他の規範に入れることを決定します。次に、通常は明示的な推論なしで、またはこれがベストプラクティスであることを指摘する循環的な推論なしでそこに置かれます。
この特定の実践の理由は、同様に実際的なものです。アリスとボブがアカウントを共有していて、何か悪いことが起こった場合、どちらも相手を指し示し、誰がそれをしたのかを知る方法がありません。個人のアカウントを使用すると、侵害されたと主張しますが、少なくとも、さらに調査する必要があります。
コンプライアンスなどの多くのサブフィールドで説明責任に関する明確な要件もあり、それらはこれに関係しています。
そのルールの例外は1つだけ知っています。複数のユーザーによって共有される単一のマシンがあり、次のアサーションはすべて真です。
- これらのユーザーの1人だけがいつでもこのマシンを担当しています
- アカウントはローカルマシンでのみ使用できます-ネットワーク経由で無効化
これは7/7 24/24システムで発生する可能性があります。そのユースケースでは、上記の2番目のルールを設定できれば、特定の時点に存在していたユーザーを知ることで、容認できる入力可能性を維持できます。しかし、実際には、パスワードのないアカウントを持ち、物理的なセキュリティのみを使用することと同じです。
まだ言及されていないもう1つの問題は、誰かが自分のアカウントにアクセスしている、またはアクセスしていない、またはアクセスしていないという通知を受け取った場合、他の誰かがそうすることを期待していないということです。許可された人がアカウントにアクセスした可能性があると考えた場合よりも、アラームを鳴らす可能性がはるかに高くなります。
誰かが自分に代わって特定のアクションを実行することを誰かに許可する必要があるかもしれないケースの数を考えると、サービスが、アカウントが限られた権限で二次資格情報を許可し、取り消すことができる手段を含めることができれば、非常に役立ちます。 。これにより、システムはアカウントにアクセスするために使用された資格情報を報告できるようになるため、誰かが予期したアクティビティと予期しないアクティビティをより適切に区別できるようになります。
ここでは、理解を簡単にし、簡単に復習するためのいくつかの箇条書きを示します。
説明責任
説明責任は、情報セキュリティのもう1つの重要な原則であり、アクションまたはイベントを追跡して、それらを実行したユーザー、システム、またはプロセスまで遡ってアクションまたは省略の責任を確立する可能性を指します。
コンプライアンス
GDPRへの準拠またはほとんどの規制への道を進んでいる場合は、各アカウントがアクセスできる場所に関する行を定義できる必要があります。
法的
監査の場合、侵害された、またはアクションの原因となったアカウントを特定できる必要があります。
管理および保護
アカウントを保護、管理、監視するために、異常な使用を削除、変更、および検出するための個別の個別アクセス権を持っている方が簡単です。
規制を遵守していなくても、「ベストプラクティス」に従う必要があります（推奨）。これにより、ネットワークプロセス全体を大規模に支援できます。
他の回答が指摘している監査の問題に加えて、共有ユーザーアカウントは、本質的に同じプラットフォーム上のシングルユーザーアカウントよりも安全性が低くなります。
ログインするための資格情報を知っている人が多いほど、そのアカウントの安全性は低下します。これで、ソーシャルエンジニアリング攻撃の被害者がさらに増える可能性があります。アカウントへのアクセス権を持つ追加の各人物は、そのアカウントのセキュリティに対する攻撃の別のベクトルです。ことわざにあるように、1人が死んでも2人は秘密を守ることができます。
また、心理学の観点から、共有ログインの使用には注意が必要です。監査/不正行為の懸念だけでなく、共有ログインは本質的に両方の栄光と責任の共有を意味します。あなたは個人の説明責任と労働倫理を阻害する可能性があります。それが共有プロファイルである場合、各個人はそのアカウントのセキュリティに対する責任が少なく感じられます。結局のところ、たとえパスワードマネージャーを使用したり、フィッシングメールを回避したりするなど、適切なことをすべて行っていたとしても、同僚がそうしなかった場合はどうなるでしょうか。とにかく他の人が間違ったことをしようとしているのに、なぜ彼らは余分な努力をしなければならないのですか？
さらに、共有ログインはアカウントを保護するより弱いパスワードを持っていると思います。強力なパスワードを共有し、それを複数のユーザーで適切に管理しようとすると、不便です。パスワードの脆弱性の共通点として最も低いものになる可能性があります（CompanyName01？）または、エリア内のすべての人が見られるように物理的に書き留めたパスワード。
多くの人が言ったように、説明責任、追跡可能性、責任などが主な理由です。考慮すべき追加の点がいくつかあります。
- アクセスされる情報はどの程度秘密ですか？極端な例として、多くのパブリックFTPサーバーは、（d）共有アカウント「匿名」を使用します。また、パブリックwwwサーバーにアクセスするために使用するアカウント（認証されていないアカウント）は基本的に同じではありませんか？ WPA2パスワードはどうですか？
- 会社のポリシーを作成する場合、「まあ、絶対にアカウントを共有しない」よりも「決して共有しない」アカウントを適用する方がはるかに簡単ですが、場合によっては、一緒に働く2人の間の限られた期間、実際のリスクが低い場合は、それを行うかもしれません。」.
- 共有アカウントには管理上の負担もあります。すでに与えられている例は、誰かが去ったときにパスワードを変更する必要性です。
- 一部のアカウントは共有する必要があります。例は、Unix/Linuxの
rootです。はい、本番環境でのrootの使用には多くの制限を課します。たとえば、広範なログとセキュリティの監視、パスワードボールトなどを伴うSudoですが、それでも共有アカウントです。