サードパーティのパスワードをプレーンテキストで保存することは悪い考えであることを上司にどのように説得できますか？
あいまいな状態を保つ-私はクライアントのコンプライアンス問題を扱う会社で働いています。多くの場合、これは、さまざまなエンティティのさまざまなアカウントにログオンする必要があることを意味します。ユーザー名とパスワードは、ユーザーが覚えやすくアクセスしやすくするため、およびアカウントにログオンできるようにするために保存されます。
1分間ログインを共有するというセキュリティ上の悪夢を完全に無視すると、ユーザー名とパスワードはプレーンテキストで保存されているように見えます。ばんざーい。
どうすれば上司と上層部を説得できますかA）これはひどい考えですB）これらを保存するより良い方法/方法
なぜそれがひどい考えなのですか？
他のユーザーのログイン資格情報を記録することにより、会社は責任を引き継ぎます。同社は現在、これらの資格情報を使用して発生する可能性のある悪意を担当しているため、リスクを最小限に抑えるための措置を講じる必要があります。さらに、あなたとやり取りする企業は、あなたを信頼する責任を負わなければなりません。これは、インシデントが公開された場合にビジネスに害を及ぼす可能性があるものです（symbeanが言及）。
（ご存じのように）パスワードをプレーンテキストで保存しても、そのリスクに対する保護は提供されません。
より良い解決策は何ですか？
コメントで述べたように、必要なのはpassword managerのようなものです。実際、必要なものはパスワードマネージャーです。
暗号化に関しては多くのエラーの余地があるため、確立されたパスワードマネージャーを使用することをお勧めします。オンラインで数え切れないほどの比較を見つけることができますが、最終的にはGUIに基づく比較（1password、LastPass、keepassなど）または自動化されたアクセス用のcli（パスまたはLastPass CLIなど）を選択できます。
はい、あなたはひどく悪いことをしています。あなたの雇用主がコンプライアンスを専門としているように見えることは、それをはるかに悪化させます。会社のビジネスは、あなたが積極的に取り入れているコンプライアンスの卓越性に対する評判に基づいています。
残念ながら、組織のすべてのレベルで、上司が現在行っていることは悪い考えであることを上司に納得させることは困難です。私があなただったら、次の場合にクライアントの反応を検討することをお勧めします。
- 資格情報をクリアテキストで保存するように言われました（おそらく使用に関するリリース/監査コントロールがない）
- 彼らは、この慣行の結果として別のクライアントが侵害されたことを紙で読んだ
betterアプローチとは...実際にはrightアプローチが必要であり、機密性、整合性、可用性、および予算のバランスをとります。これに役立つ商用およびオープンソース製品がありますが、このフォーラムに適したものよりも多くの調査と分析が必要になります。
ユーザーのパスワードをKeePassなどに保存する必要はまったくありません。
- 情報はデフォルトで非表示になっていますが、引き続き簡単に表示できます
- パスワードは簡単に共有され、説明責任が失われます。つまり、自分のアカウントを使用している他の誰かではなく、それがユーザーであることをどのようにして知るのですか？
- パスワードが更新された場合（たとえば、不正なエージェントが発見され、それ以上アクセスできないようにしたい場合）、パスワードは使用されている他のすべての場所で更新する必要があります
これらは、シナリオごとに分類されたいくつかのオプションです。
使用しているシステムが独自のものであり、アクティブに保守されている場合は、ユーザーのなりすまし機能を要求できます。管理者アクセス権を持つ各ユーザーは、自分のパスワードを知らなくても基本ユーザーのアカウントに切り替えることができる自分の管理者アカウントでログインします。このようにして、より良い監査を行うことができます。アクションを実行しているのは実際のユーザーではなく、特定の管理ユーザーがユーザーを偽装していることがわかります。これにより、ユーザーと管理者の両方が保護されます。ユーザーが管理者パスワードを持っていること、または管理者がユーザーのパスワードを所有していて、自分のアカウントを直接使用していることが証明されない限り、どちらも悪意を訴えることはできません。
- あなたは自分のパスワードを知っているだけで、脅かされていても他のユーザーのパスワードを見つけることはできません（適切なハッシュスキームでは、パスワードごとに平均して数百年かかります）
- あなたは自分の行動に対してのみ責任を負い、他の誰にも責任を負わない
- ユーザーのパスワードが更新されても、アカウントへのアクセス方法は変更されないため、影響はありません
システムが外部、つまりサードパーティである場合、同じ種類のユーザースプーフィング機能をネゴシエートすることを試みることができます。これは、優先度が非常に低い場合や、企業によっては優先度が低い場合もあることに注意してください。 、または非常にゆっくりと発生する可能性があります（年を考える）。
システムが保守されなくなった場合は、運が悪かったことになります。リスクのためにそれらの使用を停止するか、パスワードをローカルに保存してリスクを受け入れることを選択します。
if違反が発生する問題ではありませんが、-when違反が発生することを覚えておいてください。
はい、複数あります。プレーンテキストでパスワードを保存することは明らかに悪い考えです。それらを暗号化する方が良いですが、通常、パスワードはまったく保存されません。 不可逆ハッシュ が代わりに格納されます。
しかし、ここでのより大きな問題は、ユーザーのパスワードを使用してフォームに入力するということは、これらのパスワードで誰が何をしたかを知る方法がないということです。顧客ベースのユーザーの1人が、何か違法なことをしたり、違法であったりするとします。彼らはそれがあなたの組織の誰かであったに違いないと主張します。それがそうではなかったことを証明できますか？ユーザーはあなたがパスワードにアクセスできることを知っていますよね？
そして、他の回答で述べたように、第三者がこれらの資格情報を取得して使用する可能性が高くなります。これが発生した場合は、組織が再び非難の対象となる可能性があります。
私があなただったら、あなたが聞くことができる人なら誰にでもそのリスクを説明します。私が正しく理解していれば、これらの資格情報はサードパーティシステム用です。理想的には、内部ユーザー向けのシステム上にアカウントを持つことになります。それができない場合は、組織内のユーザーが各システムにアクセスしているときにパスワードとログを見ることができないような何らかの実装を試みる必要があります。
他人の外部アカウントにログインする必要がある場合は、そのユーザー名とパスワードが必要です。それを回避する方法はありません。ハッシュや暗号化はできません1 それらには、プレーンな値が必要です。
もちろん、これは悪夢です。ユーザーが自分の資格情報をあなたに開示する必要があるからです。彼らはあなたが彼らを乱用していないと信じています。それらを意図的に悪用していない（ビジネスモデルの一部として闇市場でそれらを販売するなど）と仮定すると、漏洩を防ぐ必要があります。これには、インフラストラクチャのデータ侵害や、データベース管理者がそれらにアクセスできることが含まれます。したがって、ここでのベストプラクティスはまったく保存しないです。あなたの会社のビジネスは、パスワードマネージャーサービスを提供するのではなく、ユーザーがフォームに記入するのを助けることです。 「[ユーザー]が覚えやすくする」ために、資格はあなたの仕事ではありません。
1つの解決策は、ユーザーがインストールするブラウザー拡張機能を作成することです。彼らは自分のマシンでそれらの外国のアカウントに自分でログインし、あなたのプラグインはそこで仕事をします。サーバーが資格情報に接触することすらありません。 （もちろん、ユーザーは拡張機能を信頼して、それらをスパイしないようにする必要があります）。
それがオプションではなく、ログインを含む作業をサーバーで行う必要がある場合でも、ユーザーの資格情報を保存しないでください。それらを外部ログインサービスに転送し、APIで使用されるセッショントークンを、必要な間だけデータベースに保存します。データベースが侵害された場合、攻撃者はセッションをハイジャックできる可能性があります（さらに悪いことです）が、プレーンテキストのパスワードは取得できません。サーバーに複数回ログインする必要がある場合は、ユーザーに資格情報をもう一度提供してもらいます。
1：もちろん、機密データをどこかに保存するときは常に暗号化する必要がありますが、最終的にはその鍵がサーバーのどこかに存在しなければなりません。想定される攻撃者もアクセス権を取得する可能性があります。
マネージャーは、テクノロジーではなくビジネスの言語を話します。
貴社がこれらのプラクティスに直面しているリスクの見積もりを、通貨（USD、EUR、適切なもの）で示します。それにはさまざまな方法があります。良いアプローチは、現実的なシナリオと最悪のシナリオの両方を推定することです。会社に最大500万の損害を与える可能性があるセキュリティインシデントの可能性が1年に10％あることをマネージャーに伝えることは、彼の耳に入るはずです。
あなたの顧客会社によるあなたに対するあなたへの契約クレームからの潜在的な損害に加えて、あなたはまた、重大な過失によって引き起こされた民事および刑事責任に注意するべきです。刑務所に行くチャンスは、マネージャーの注意を引く傾向があるもう一つのことです。
あなたの会社がリスク管理を実施している場合は、方法と見積もりに関してそこからの担当者と調整してください。企業慣行に従うと、あなたのアプローチがより立派になります。
最小必要な予防策は、a）暗号化されたパスワードを保存し、b）必要なときに必要なパスワードのみを復号化するパスワードマネージャーまたはその他のシステムを使用することです。
証明書ベースの方法に移行するのが理想的ですが、これはクライアントにも依存し、完全には制御できません。
また、パスワードの処理方法を文書化し、違反した場合の罰則を含むパスワード処理ポリシーを用意する必要があります。出力フィルターは、電子メールの災害を防ぐことができます。
はい、プレーンテキストのパスワードを保存するのは簡単ではありません。コピーアンドペーストの事故で、1人のスタッフが誤ってすべての「保存された」パスワードを内部配布リストにメールで送信していた。幸いにもリストに顧客はいませんでした。
そこで、パスワード情報の集中データベースとして非常に機能するTeampassを使用するようにしました。
異なるレベルのアクセス権を持つグループも可能であり、各ユーザーは、他の誰もが読み取ることのできない独自のプライベートパスワードのセットを保存できます。
これは、誰もがローカルでパスワードのコピーを保持する個別のパスワードマネージャからのセットアップです。したがって、サービスのパスワードが更新されると、誰もがその更新を見ることができます。
履歴も維持されるため、サービスXの以前のパスワードを取得できます（1つのホストが更新されなかったため、時間を遡る必要がある場合があります）。
明白なものを除いた別の角度（質問で示したように、暗号化されていないパスワードを保存することは悪いことです）：
パスワードを共有/提供しないことは、セキュリティガイドラインの最初の箇条書きの1つです。正気の銀行、オンラインサービス、またはエンティティがパスワードを要求することはありません。これは、正当な理由により、すべてのユーザーに根付いています。
私があなたのクライアントであり、あなたの雇用主からパスワードを求められた場合、私はそれをa）あなたに教えないで、b）私の経営陣にすぐに駆けつけます。私たちがあなたのクライアントではなくなったことを確認するように心がけています。
私は自分のサポート担当者に自分のパスワードを提供することもしません（サポートセッション中にログインを要求される可能性は低いですが、自分で担当します）。私はセキュリティチェック（システムまたはアプリケーション、あるいはその両方）の受信側にいて、neverは実際のユーザーアカウントをセキュリティ会社に渡しています。ログインする必要がある場合は、自分の一時的なアカウントを取得しています。私は顧客にパスワードを教えてもらうように言われました、そして私は彼らをすぐに中断して彼らに自分でそれをタイプさせることをかなり確実にします。
TL; DR：あなたの経営陣にこの答えを見せてください-私はあなたに1人の顧客を失ってしまいます。