共有ユーザーとしてログインするのは悪い習慣ですか?


35

私は、マシンにログインしたい人ごとに新しいUbuntuユーザーを作成する代わりに、sysadminsが各ユーザーのsshキーをに追加し.ssh/authorized_keys、全員sshを(たとえばubuntu@hostまたはとしてマシンに追加する組織で働いてきましたec2-user@host。(ちなみに、これはラボ環境で共有されたMac miniで実践されています。)これは受け入れられた実践ですか、それともアンチパターンですか?

問題のホストは主にテストに使用されますが、通常はユーザーごとの構成を必要とし、特定のユーザーによって実行されていると追跡されるアクションもあります。たとえば、現在gitコミットを作成およびプッシュします。ユーザー。


23
多くの人が多好色な関係に問題がありますが、私はそれを共有するために、必ずしも「悪い癖」だとは思わないので、他の人は、うまくそれらを扱う...ああ、用事は、ユーザーの意図アカウントを
HopelessN00b

Awww、誰かがクリックベイトのタイトルを編集した.. :(
ブルギ

回答:


42

はい、それは悪い習慣です。これは、悪意のある人はいません(または悪意がある)、そして誰も間違いを犯さないという基本的な前提に依存しています。共有アカウントを持っていると、説明責任や制限なしで何かが起こるのが簡単になります。ユーザーが何かを壊すと、誰にとってもそれが壊れてしまいます。

このuid-sharingスキームの理由が新しいアカウントの作成と構成の共有の管理コストを削減することだけである場合、おそらく管理者はユーザーの作成などを行うAnsibleChefPuppetまたはSaltなどの自動化システムに時間をかける必要があります複数のマシン上のアカウントは非常に簡単です。


4
それは悪意すらありませんし、無能でもありません。何かがうまくいかないときは、このアカウントで行われたことを思い出したとは思いません。
-djechlin

安全なデータの原則:整合性機密性可用性説明責任。説明責任という言葉を使用して+1
DeveloperWeeks

7

これから始めることは私に衝撃を与えません、そして、私は非常に安全な環境で働いています。誰もが自分のユーザーとマシンとsshキーを持ち、必要に応じてロギングリレーを介して、rootまたは別のユーザーとしてsshでサーバーを操作します。私たちが行うことはすべて、sshキーの所有者によって行われたとして記録されるため、説明責任は問題ありません。

代替手段は何でしょうか?ルートは言うまでもなく、多くのことを特定のユーザーとして実行する必要があります。須藤?特定の非常に制限されたタスクでは問題ありませんが、マシンのシステム管理では問題ありません。

しかし、最後の段落についてはわかりませんが、誰かがgit commitを一般ユーザーにプッシュできるということですか?それは説明責任を破り、説明責任を破ることは悪いことです。ログインしているマシンからgitを実行し、sshキーでgitを認証します...

認証、許可、アカウンティング(AAA)は古典的な表現です:あなたはsshキーで認証され、キーがauthorized_keysにあるので一般ユーザーができることは何でも許可されており、あなたがすることでアカウンティングが必要です事後確認できます。


3
汎用ユーザーには、gitリポジトリの変更が許可されている何らかの認証(sshキー?)がありますか?それは本当に良くありません。そのコミットの説明責任を破るだけでなく、誰でもそのキーをコピーして他の場所から使用できるためです。この種の問題が発生したら、コードまたは差分をローカルマシンにコピーし、そこからコミットします。
法律

2
sudoマシンの一般的な管理にまったく受け入れられないのはなぜですか?
ブラックライトシャイニング

4
「非常に安全な環境」でルートとしてsshしますか?
-xaa

@BlacklightShining何か(chown、chmod任意のファイル、サーバーのインストール、ファイルシステムのマウント)を実行できるようにする必要がある場合、ユーザーとしてsshing inし、sudo bashを実行しても何も得られません。代わりに、ロギングリレーを使用してsshおよび/またはsshしたsshキーの所有者ですべてをリモートサーバーに記録します
。– Law29

1
@xaaはい、私はそうしますが、それに関する問題は見当たりません。入力したものはすべて他のマシンに記録されます。「ルートとして機能しない」は、マシンがサーバーであり、実行する可能性のあるすべてがルートである必要がある場合、まったく役に立たない格言です。
法律

3

それは明らかにシステムのユースケースに依存します。時々テストするためのシステムであれば、私にとっては問題ありません。そのようなシステムもあります。会社にID管理(LDAP、IPA)の種類がない場合、ランダムシステムでのリモートコントロールなしで新しいユーザーを作成することは非常に負担となります。

しかし、誰かのミスが会社全体を運営できなくするような毎日の仕事にとっては良い考えではありません。


正確に言えば、ディレクトリサービスがない場合やできない場合は、数千のアカウントを作成して管理することは実用的ではありません。
ジムB

LDAPを使用できない場合でも、SSHアクセス(またはWindowsのPowershell)を使用する可能性があります。これらすべてのアカウントのホスト上のauthorized_keysファイルを管理する方法(パスワードを共有している場合を除く)やその他の設定が必要になります。多数のユーザーまたはサーバーがある場合、なんらかの種類の構成管理(Puppet、Chef、Ansibleなど)を使用していない理由を疑問に思う必要があります。その負担を取り除き、見返りにプロセス制御、説明責任、監査能力を提供します。
マーティン・ヘメルズ

3

これらの回答はすべて、それ自体が重要かつ現実的な問題である説明責任の懸念に対処していますが、共有アカウントを使用することで、他のユーザーへのささいな攻撃も可能になります。

ssh入力したパスワードを記録する悪意のあるスクリプトを作成し、PATHその共有ユーザーのパスワードを入力する攻撃者を考えてみましょう(簡単に実行できます)。これで、共有ユーザーでそのマシンにログオンし、ssh他の場所(今回は個人の共有されていないアカウントで)に行くことにした次の人は、意外な驚きを感じるかもしれません。

基本的に、コンピューターで共有アカウントを使用することは、公共のスイミングプールの足湯から飲むようなものです。


1

一般的に、1つのアカウントを共有することは、次の理由から悪い考えです。

  1. このユーザーに対して行われるすべての設定は、ログインするすべてのユーザーに影響を与えます(Promt、エイリアス、...)
    1. あなたは誰が何をしたのかを知る可能性を失います(説明責任)
    2. アカウントの設定の1つの間違い(たとえば、ssh kayを誤って削除する)は、そのユーザーアカウントを使用している全員に影響します(この例ではロックアウト)。

そして、さらに多くのマイナス面があることを確かめてください...しかし、私はそれ以上入りたくありません。

ポイントは、すべての管理者がアクセスできる特定のユーザーアカウントで実行されるサービスを管理するために、アカウントを共有する必要に直面している可能性があることです。

このような設定では、ログインするためにこのアカウントを共有する可能性があります(上記の理由のために私はそうしません)または個別にログインし、ユーザーを共有アカウントに切り替えます(私はお勧めします)。

監査ツールを使用すると、誰が何を実行したが同じアカウントを共有しているのかを追跡できます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.