私は政府機関でインターンシップを始めたばかりで、最初の仕事は 120 台以上の Redhat および Windows サーバーからなる社内サーバー ファームのユーザー システムを開発することです。社内サーバー ファームは Puppet で管理されています。現状では、全員が同じ root/admin アカウントでログインしています。さまざまな理由から、これが大きな問題になっているのは明らかです。正確な数字はわかりませんが、少なくとも 30 人が同じアカウントを使用していることになります。また、彼らの仕事の多くは、そのレベルのアクセス/権限を必要としません。この問題に対して 2 つの解決策を提案しましたが、皆さんからのフィードバックをいただければ幸いです。
1) AD経由でサーバーファームへの認証
アイデアとしては、SSSD/FreeIPA を使用して政府の AD に接続された認証サーバー (冗長性のために 2 つが望ましい) を設定し、ユーザーが認証されると、サーバー ファームへのアクセスが許可され、そこで Puppet を使用して権限が管理されます。この組織は AD を制御する上位インスタンスによって管理されているため、AD を通じて権限を管理するという選択肢はありません。私のマネージャーと私はこのソリューションを好みます。他の管理者にアカウントを管理させられるため、2 つの別々のシステムを持つ必要がなくなるからです。政府組織がメインの AD とは別に別のユーザー システムを持っている場合、ユーザー アクティビティに関する月次レポートを提供する必要がありますが、私の部門は非常に忙しいため、そのようなタスクは避けたいと考えています。
2) ユーザー権限のローカル管理
もう 1 つの解決策は、認証サーバーを廃止し、ユーザー システムとその権限を Puppet で管理することです。こうすれば、完全に制御でき、管理者に頼る必要がありません。この方法の欠点は、管理する必要がある別のユーザー システムが必要になることです。もちろん、古い従業員やコンサルタントがシステムから削除されない場合、セキュリティ上の脅威になる可能性がありますが、最も重要なのは、時間のかかる別のタスクに費やす時間がないということです。
この件に関する記事や他の投稿を読んで、SSSD/FreeIPA がおそらく最適な方法だと理解しましたが、確信はありません。皆さんはどう思いますか? 提案された解決策のうちどれが最適でしょうか? また、この問題に対する 3 つ目の、より良い解決策はあるでしょうか?
前もって感謝します！
答え1
米国政府の研究所で働いている人からの回答です。システムを AD ドメインに参加させます。realmツールは Red Hat 7 でうまく機能します。ユーザー認証用に sssd を構成します。puppet を使用して /etc/security/access.conf を管理し、ユーザー アクセスを制御します。puppet は /etc/sudoers と /etc/sudoers.d も制御します。基本的には、オプション 1 を使用します。また、syslog を設定して、すべてのセキュリティ ログをアクセス制限のある中央ログ サーバーに送信します。これで、メイン AD によって制御されるアカウントが 1 つ減りました。すべてのログインと sudo 要求は中央 syslog サーバーに記録されるため、使用状況レポートを取得する場所が 1 つあります。また、root アカウントをロックダウンして ssh 経由でログインできないようにし、su または sudo を使用するように強制します。マネージャーに、su を日常的なオプションとして使用しないように依頼します。
インターンシップがうまくいくことを祈っています。これは実行する価値のある素晴らしいプロジェクトです。