すべてのサーバーでrootアカウントが無効になっています（sp_pwdpが*に設定されています）。これは、すべてのルートアクセスにSudoを必要とするためです。[1]これの目的は、すべてのスーパーユーザーアクティビティを監査して、システムに対して何が行われたかを人々が確認できるようにすることです。
よりハードコアなオプションについては、Sudoをログファイルに書き込み（syslogとは対照的に）、ファイルを追加のみにすることができます（Linuxではchattrを使用）。またはBSDではchflags）。この方法では、後で監査を編集することはできません。
[1]また、ルートシェルを実行しない、またはルートプロセスからシェルエスケープを実行しないというポリシーもあります。 （ただし、パイプラインやリダイレクトを行う場合はSudo sh -c '...'を使用してもかまいません。）
I 強調 rootユーザーを無効にしないことをお勧めします。 rootログインを無効にするか制限します（securetty and経由でsshd_config and PAM経由and経由で）システムで許可されている場合は、rootの権限を制限しますまたは、ルートの役割を分割します（方法と同様 [〜＃〜] rsbac [〜＃〜] がそれを行います。）しかし、ください、パスワードを削除してrootアカウントを無効にしないでください。無効にしないと、sulogin経由でシステムにログインできなくなります。 suloginは、fsckによって深刻なエラーが報告された場合に知っているすべてのinitscriptで使用されます。つまり、ルートファイルシステムが破損すると、システムからロックアウトされます。
明確にするために、「パスワードを削除してrootアカウントを無効にする」とは、最終的に！または/ etc/shadowのパスワードフィールドの*など。 「rootログインメカニズムを変更して、パスワードの入力を求められないようにする」という意味ではありません。
すべてのサーバーでrootアカウントを有効にしています。すべての管理者は独自のユーザーを持ち、それを介してログインする必要があります。そこからルートに切り替わります。 （ルートsshが無効になっています）
管理者の数を少なくしてください。そのサーバーで本当にrootアクセスが必要な人だけがパスワードを持っています。
私は須藤のファンではありません。ルートシェルに対して「Sudo bash」を実行するのは簡単すぎます。これは無効にできることは知っていますが、なぜわざわざですか？管理者タスクを実行し、互いに対話できるユーザーを制限するだけです。ルート端末を無人で開かせないというポリシーがあります。ログイン、su、作業、ログアウトです。
注：私はかなり小さな会社（50代の従業員）で働いており、パートタイムの管理者は2人（1つはWindows/1 Linux）しかありません。この方法は、桁違いに多くのユーザーがいる場合には最適ではない可能性があります。私は個人的にはまだSudoを使用しないでしょう。ルートアクティビティをログに記録する方法は他にもあります。
Rootパスワードを無効にすることは、誤った「良いアイデア」です。あなたがそれを必要とする日、あなたはそれを本当に必要とします。 （構成によっては、たとえば、シングルユーザーモードでログインするために必要になる場合があります）
ルートリモートログインを無効にすることは関連があるかもしれませんが、ローカルにログオンできる場合のみです。
はい、Sudoはすべてのサーバーにインストールする必要があります。便利で設定が簡単です。なぜそれを使わないのですか？
RootのSSHアクセスを無効にし、ユーザー（多くの場合、開発者のみ）にsshキーの使用を要求します。辞書攻撃が多すぎて、SSHポートを変更することは私たちの選択肢ではありません。
そうすれば、適切なパスワードを書くために誰かの能力を信頼する必要はありません。内部に入ると、管理者だけがSudoの権限を持ちます。
私はこのスレッドが本当に古いことを知っていますが、リンクされた記事のロジックにいくつかの大きな欠陥があり、私は「不平」を感じています-Sudoはホワイトリストとブラックリストの両方を許可しています。リンクされた記事で指定されている黒だけではない-これはAAA（認証、承認、監査）の概念をスキップします-suとSudoは段階的な認証と説明責任の両方を可能にします。
シナリオ1管理者が誤っていくつかの不正なコードをシステムに導入し、rootとしてログインすると、コードは完全なアクセス権を持ち、管理者は何が起こったのかを決して知ることができません。少なくとも段階的なログイン（例：su/Sudo）では、不正なコードが昇格した権限を使用しようとすると、管理者は認証を求められます...昇格しない場合は、ユーザーの権限に限定されるため、最小限のダメージしか得られません。
シナリオ2悪意のある管理者が情報を入手したい/変更したい。コンソール（物理コンソールアクセス、HP iLo/similar、またはvGuestコンソールアクセス）に接続し、rootとしてログインして、好きなように操作します。コンソールアクセスを取得するために使用される名前付きアカウント/アクセスカードがない限り、おそらく監査証跡はあまりありません。
- 彼らが本当の自分であるかを確認してください。個人情報の盗難は問題ではなく、個人情報の検証が問題です。
- 権限を確認し、そのときに必要なものだけを提供します。段階的な承認により、必要なときに昇格できます。
- すべてを監査し、記録を残しておくと、誰が、何を、いつ、どこで行ったかがわかります。できればなぜか
Owlセキュアディストリビューションの作成者（およびソーラーデザイナー）は、反対の慎重に正当化された見解を持っています。たとえば、回答 https://unix.stackexchange.com/questions/8581/which-is-the-safest-way-to-get-root-privileges-Sudo-su-or-login/ 8660＃866 彼らの主張のプレゼンテーション。スーパーユーザーのアクション（誰が何をしたか）を監査する問題も、彼らの視点で扱われます（基本的に、解決策は、複数のrootユーザーに異なる名前を付けることです）。
すべてのrootコマンドに対してポリシーとしてSudoを使用するように全員に要求する必要があります。 「Sudo bash」などを実行する理由は決してありません。それは、無知のため、または自分のトラックをカバーするために、便宜のためだけです。
Rootアカウントへのログインを直接無効にすると、深刻な問題が発生したときにシステムを修正する能力が損なわれます。
管理者が自分自身でログインし、rootとして実行されるすべてのコマンドに対してSudoを実行するように説得できず、シェルから抜け出さない場合、技術的な解決策がない深刻な問題があります。