これは技術的な質問ではありません。小規模組織は、プロダクションサーバーへのルートパスワードなど、いくつかの個人間で共有する必要がある機密情報をどのように安全に保つことができますか？アクセスを必要とするすべての人が同じ場所で作業するわけではありません。新しいパスワードは電話で配布することができますが、パスワードを保存する際にチームメンバーにはどのようなルールを適用する必要がありますか？小規模グループの本番パスワードを保存するためのベストプラクティス
更新：この質問は、ルートパスワードの適切な使用に関するものではありません。より良い例は、SSLパスフレーズまたは管理タスクを実行している人の間で共有されなければならない他のパスワードです。実際には、ルートパスワードなどを生成して保存する必要があり、通常は複数の人がアクセスする必要があります。質問はストレージプロトコルに関するものです。ありがとう。
個人的には、パスワードを保存するためにkeepassやroboformのようなものを使用することをお勧めします。これらのプログラムは、個人が覚えているマスターパスワードを使用してサムドライブ上のパスワードを暗号化します。そのため、マスターパスワードのみを覚えておく必要があります。誰かがサムドライブを失った場合、侵入したサムドライブを報告し、パスワードを変更できる時間帯があります。親指のドライブを盗んだ人がマスターパスワードを強制的に強制して、他のすべての保存されたパスワードを得る前に、マスターパスワードの強さに応じて少し時間がかかります。
さらに、3人以上のアカウントを共有することは避けてください。！代わりに、同等のアクセス権を持つアカウントを各個人に作成することを検討してください。悪意のある従業員が共有されているアカウントにアクセスできる場合、アカウントを共有している複数のユーザーがいた可能性があるため、悪質なものを実行することが有益である可能性があります。
これは、誰かが終了するたびにパスワードを変更する必要がないことを意味します。代わりに、自分のアカウントを無効/削除するだけです。したがって、管理するアカウントが増えたにもかかわらず、変更されたパスワードを誰にも知らせる必要がないため、誰かが離れるとオーバーヘッドが少なくなります。
編集：ああRoboformには、SSLによるオンラインパスワード同期サービスもあります。だから、あなたは単に人々が同期を介してパスワードを取得させることができます。一度それに慣れればそれはちょっと涼しいです。
サーバー、プロダクションなどにルートパスワードを渡す（または使用する）べきではありません。パスワードを共有しないでください。
ユーザーは、自身のユーザーID（）を使用して自分自身（認証）としてログインする必要があります。それは写真の半分です。
正しくログインすると、必要に応じて権利（画像の認証側）を与える必要があります。一般的なOSの目的にはsudo、データベースなどの権利メカニズムは利用できます。
これらは2つの異なる問題です。ストリームを渡ってはいけません！
sudoの出現で、rootパスワードを使用することはめったにありません。私の古い店では、ルートパスワードはカードに書き込まれ、封筒で封印され、システム管理者の領域の引き出しにロックされていました。知りたい人は引き出しの鍵を持っていました。
パスワードを変更して新しいパスワードを新しい封筒に入れてください。封筒は頻繁に開かれませんでした。
このシステムはおそらく本当に悪いプロの練習ですが、みんながみんな知っていた小さなお店ではうまくいきました。
パスワードを共有するには、anypasswordproのようなプログラムを使用できます。暗号化されており、アクセスレベルがあります。
現実的です。あなたが気に入っているかどうかに関わらず、小規模チームの人々は、特に脅威に気づいていないときに、付箋紙にパスワードを書いたり、IMしたり、電子メールで誘惑したりするように誘惑されます。
小規模なグループで便利だとわかった尺度の1つは、難読化プロトコルを確立することです。
例えば、ボイスメール、電子メール、IM、または紙を介して通信または保存されたすべてのパスワードは、音声学））自分のキャラクターの順序は 2を逆に）各パスワード文字 3の間に配置されたランダムな文字や単語を 1を持っています発音されたパスワード文字。例えば
：
パスワード：VMaccp @ SS1
は難読化：SDおしっこに1つの2個のESのDF ES 23は、DFSはFXZのAY DF EMキーが確立することであるVEE
をSD見るFD誰かがプロトコルを知らなくても理解することは事実上不可能な、ある種のエンコーディングです。これは覚えやすいです。
生死死のない小規模グループのためのものです。明らかに、大規模なグループや非常に敏感な財務データを保護するグループにとっては、より煩雑な対策が適切です。私が以前働いていたプロトタイプ& R & Dラボでは、などの根のようなもののための「標準的な」実験室のパスワード、コンソールへの管理アクセス、スイッチは、
があったこれらは、単純で覚えやすい、として口頭で共有されています誰かがそれを必要とした。一般に、あなたが物理的にラボに入ることができれば、あなたはこれらのパスワードを持つことができます。
製造施設では、新しいシステムが構築され、顧客用に構成されました。顧客はすべてのパスワードを選択する必要があり、システムとともにラックに取り付けられた一連のフォームに印刷されました。リモートアクセスは必要に応じて提供され、パスワードは電子メールで送信されたか、電話で通知されました。これらのパスワードは、システムが提供されるとすぐに顧客が変更することが完全に予想されていました。
IT &プロダクションラボでは、ほとんど誰もルートにアクセスできませんでした。ほとんどの人は、制限のないところでsudoのアクセス権を持ち、人とシステムによっては仮想ファイルシステムをマウントする機能しか持っていませんでした。 rootとしてシェルを起動するためにsudoにアクセスすることは非常にまれです。これにより、rootとして実行したすべてのコマンドのログトレイルが非常に明確になりました。そのログは、何年にもわたり1人以上の人が&の羽毛をタールするのに使用されました。
私は何年も前のヘルプデスク/サポートの役割で、各ツールの専門家が独自の管理パスワードを選んだ。これらは、機械室の金庫に入れられた封筒に記録されていました。誰かが管理者アクセスを必要とする場合は、封筒を開き、パスワードを読んで、パスワードを知っていることをログに記録してから、封筒にパスワードを再封印することができます。パスワードを変更する必要があるかどうかは、ツールの所有者が決定しました。このシステムは5年以上使用されていました。あるケースでは、チームメンバーの「バステスト」（心臓発作）に耐えるためにプロジェクトが実際に役立ちました。
さまざまな種類のシステムとラボ用の異なる基準。それは合理的です。私は、パスワードが断片化される必要があるとき、パスワードがシンプルで、短く、口頭で（個人でも電話でも）伝えられるならば、それが最良であることを知ります。私は決して共有するべきではない唯一のパスワードが私の個人的なアカウントのためのものであることを知ります。 root/admin/tool固有のパスワードは、何らかの方法で記録されていなければ、少なくとも1つの他のヘッドにバックアップする必要があります。