リモートLinux管理コンサルタント-ベストプラクティス[終了]

私たちは、Linux管理者としてインドのコンサルタントを雇っています。私たちは彼をよく知らないので、彼は仕事をするためにすべてのサーバーへのルートアクセスを必要とします（セキュリティ監査を含む）。

悪意のある活動から保護されるように、リモートコンサルタントがそのような作業を行えるようにするためのベストプラクティスは何ですか？

前もって感謝します。

しないでください。また、あなたははるかに危険としている愚かとして悪意私は、企業がこれを処理する一般的な方法を見てきたものから。

私はおそらくあります、言いたい偉大なインドではそこからシステム管理者が、道の多くの企業は、物事を行うにはひどいです。

ボディショップを行っている場合、かなり大きなカットが見られる可能性が高く、従業員の多くが適切に審査されている可能性は低いでしょう。私は3、私が働いていた人のいずれかに話をしましたし、どれもそれらのは、技術的なインタビューを行っていません。

ですから、あなたがリモートで誰かを雇わなければならない場合、神のために、彼自身にインタビューし、彼が彼の仕事を知っていることを確認してください。システム管理は、盲目的に誰かに引き渡すにはあまりにも重要です

「不適切」な部分を処理したので、

管理はかなり広いフレーズです。そして、rootアクセス権を持つ人は何でもできます。今、個人的には、管理者用のアカウントを作成し、sudoで自分自身を昇格できるようにすることをお勧めします（多くのサーバーがある場合、構成管理システムが処理する必要があります）。とはいえ、それでもある程度の信頼に依存しています。不満を抱いたシステム管理者が行うことのできる重大な損害については、非常に多くの物語があります。すべてのパスワードを変更しますか？確かにあなたは最終的に入ることができますが、それは些細なことではなく、おそらくあなたが節約している以上の費用がかかるでしょう。

だから、ローカルを検討してください。そうでない場合は、自分で吟味して直接雇用した人を考えてください。

前述したように、これをしないでください。

自分を守ることができる唯一の方法は、次のようなことをすることです。

1. コンサルタントが選択した構成管理システムを使用することを主張します。
2. コンサルタントは、完了が必要なアクションの構成管理マニフェストを作成します。
3. コンサルタントは、テストシステムでマニフェストをテストします。
4. 準備ができたら、コンサルタントは構成をコードリポジトリにコミットします。
5. すべての変更は、スタッフのメンバー、または最初の変更とはまったく関係がなく、連絡する方法のない別のコンサルタントのいずれかによってレビューされます。
6. 変更がサインオフされると、変更はユーザーまたはスタッフのメンバーによってサーバーに適用されます。元のコンサルタントは、どのシステムにもアクセスできません。

明らかなように、これは非常に不格好で非効率的なプロセスですが、信頼できない個人からの仕事を受け入れることを主張する場合、これは物事を処理する1つの方法です。

しかし、私が推奨したように、あなたは既知の信頼できる個人を雇うほうがはるかにましです。

悪意のある活動から保護されるように、リモートコンサルタントがそのような作業を行えるようにするためのベストプラクティスは何ですか？

法的観点から：事前のデューデリジェンスと契約違反に対する厳格な罰則。

オンプレミスのスタッフ（および/またはサービスプロバイダー）を雇用する際にも適用される通常の優れた雇用慣行から始めます。これには、提供された履歴書の事実確認、教育成績証明書と認定番号の要求、参照の確認と呼び出し、インタビュー、さらにはバックグラウンドチェックまたはセキュリティスクリーニングなど。

次に、ニンジンを適用します：公正価値を支払い、魅力的な仕事、素晴らしい同僚、良好な労働条件と福利厚生などを提供します（ピーナッツを支払うとサルが得られます）。

そして、スティック：あなたの雇用/サービス契約の条件に違反すると、私たちはあなたの弁護士を病気にし、あなたを破産させます！

残念ながら、国境とタイムゾーンを越えると、上記の両方がますます難しくなります。

誰かを雇うことに決めたら：

• 明確な指令とポリシーを使用する場合、人々はすべきこととすべきでないことを認識しておく必要があります。
• 最小限のアクセスの原則が適用されるため、人々が（偶然または意図的に）してはならないことを行うのを困難にします。通常のシステム管理者にとって、それはまだフルアクセスを意味しますが、たとえば、セキュリティ監査人は完全な管理者アクセスを必要とせず、単にレポートを作成するために必要な詳細を収集するスクリプトを既存の管理者に代わって実行するように要求できます。このようなスクリプトは、事前に簡単に確認できます。
• 信頼しますが、確認します。既存のスタッフに新しい参加者の作業を確認してもらい、常に監査情報を収集してください。
• などなど

この質問は、私がクライアントに私にリモートアクセスを確立するために通常何をするかを詳しく説明します。

頭に浮かぶあなた自身を守る一つの体系的な方法がありますが、私は言及していません。

Linuxインスタンスを仮想化ハイパーバイザー（VMware、Xenserver、Hyper-Vなど）上のVMとしてホストします。

リモート管理者にハイパーバイザーへの管理アクセスを許可しないでください。リモート管理者は、VM自体へのルートアクセスのみを取得します。

DOハイパーバイザーベースのバックアップシステム（Unitrends、Veeam、vSphere Data Protectionなど）を実装する

各Linux VMの1日に少なくとも1つのスナップショットを保持し、必要に応じて時間を遡ってください。

リモート管理者にバックアップリポジトリへの書き込みアクセスを許可しないでください。

これらを行うと、リモート管理者が制御できない各Linuxインスタンスのバックアップスナップショットが作成されます。リモート管理者が意図的または偶然に何かひねりを加えた場合、何が起こったのかを評価し、場合によってはクリーンな状態に回復するために、hinkenessが発生する前からいつでもバックアップをマウントできます。

これは、攻撃者がルートアクセス権を持つVM内からマウントされる可能性のあるハイパーバイザーサイドチャネル攻撃に対する証拠にはなりません。

バックアップが過去にさかのぼらない場合、これはあなたを保護しません。

ハイパーバイザーとバックアップインフラストラクチャを制御している人を完全に信頼する必要があります。

これをクラウド（AWS、Azureなど）で実行している場合、実装の詳細は異なりますが、一般的な概念は同じです。

基本的に、信頼できる人だけを雇用することに加えて、ビジネスパートナーではない当事者間で責任を分けます。

彼に彼自身のユーザーアカウントを与えます。次に、彼がアクセスする必要があるものを正確に見つけて、そのアクセスのみを許可しますが、それ以外は許可しません。たとえば、Apache Webサーバーを再構成する必要がある場合は、ACLを使用して、Apache構成ファイルへの書き込みアクセスsudoを許可し、Apacheサービスを再起動するがrootとして他のコマンドを実行できないように構成します。いつものように、彼にアクセスを許可しているもの（この場合は、Apache構成ファイル）のバックアップを保管してください。