ワークステーションでSSHサーバーを実行してファイルをプッシュしたり、電話から確認したりするシステム管理者を1人知っていますが、いくつかの理由でそれは悪い考えだと思います。
システム管理者がワークステーションからすべてのリモート管理タスクを実行するのを妨げるものは何もないと仮定します。管理者は、パスワードを入力するか、ワークステーションに保存されている証明書を使用する必要があります。 2要素認証は使用されていません。
運用ワークステーションでsshdを実行する際のリスクは何ですか?
(そのワークステーションには着信接続のないファイアウォールがありませんか?)
とても恐ろしい!リスクとして、これは理事会に提起されるべきです-インターネット上の攻撃者は事実上、ユーザー名とパスワード(またはSSHの0日)を見つけるだけでよく、企業ネットワーク全体が侵害されていると見なされます。ビジネスはそれなしで実行できますか?何か敏感なことはありますか?
これは多くの点で悪い考えです:
境界コントロールをバイパスします
これは重要なターゲットです
不要です
大規模な組織では、この種の機能のために、さまざまなオプションがすでに開かれています。通常は、通常のリモートアクセスソリューションを介して、ドメインアカウントの下で、SSHクライアントのあるネットワーク内の「飛び石」マシンにアクセスし、次に管理ワークステーションにログオンします。必要。
その後、各ステップで強力な制御とロギングを実施できます-管理者には少し面倒です(ログインにさらに数分かかります)攻撃者が気付かれないようにするのははるかに困難です。
それはすべて脅威モデルに帰着します。それは、リスクと攻撃の可能性に依存します。それはワークステーションが何をするかに依存します。関係するクライアントによって異なります。
これは実際のサーバーでSSHを実行するのとどのように違うのですか?サービスアカウントに多くのことを行う権限がない場合、攻撃はそれほど遠くまで到達できません。サービスアカウントが高い権限で実行されている場合、ワークステーションとサーバーのどちらで実行されているかは関係ありません。クライアントが彼の電話だけの場合、何百人もの人がそれに接続していると言うよりも、資格情報が危険にさらされるリスクが少なくなります。 SSHサーバーが特定のIPからの接続のみを受け入れるように設計されている場合は、リスクがさらに軽減されます。
ワークステーションにシステムを管理する権限がある場合、あなたが言及したいくつかの理由のために、そのワークステーションでSSHサーバーを実行することはおそらく良いことではありません。さらに良いことに、外部の世界とのつながりはないはずです。それが管理者以外のワークステーションの場合、侵害される可能性のある最悪の事態は、管理者がアクセスできるあらゆるものです。
一方で、攻撃対象領域を増やし、他方で管理性を高めます。したがって、それがシステムの管理と更新の適用に使用されている場合、それはリスクプロファイルにとって正味のプラスになる可能性があります。
この特定のケースでは、これは便宜上のものであり、リスクの高いターゲットになっています。ここでの質問は: