考えは、root/adminアカウントを盗んだり、エスカレートして自分のアクティビティをクリアしたり、攻撃の痕跡を読んだりする攻撃者を防ぐことです。 Linuxを使用していて、auditd、ログを一元管理するでログを記録し、SELinuxでMACを使用できるとします。しかし、Windowsでの回答にも興味があります。
1つの解決策は、すべてのrootアカウントがログにアクセスすることを禁止することです。ログは、logrotate、syslog、およびすべてのSIEM関連の特定のサーバー上の承認されたプロセスによってのみ管理されます。したがって、SOCのみが管理者のログを読み取って分析できます。古いログを削除できるのは、パージプロセスだけです。これが実行可能であることを誰かが確認できますか?
独自のroot権限を持つ管理者が他のrootアカウントのログを読み取ることができる、より柔軟なものを持つことは可能ですか?
これに対する受け入れられた解決策は、ログをローカルに保存するのではなく、ログサーバーに保存することです。ログが表示されたら、必要に応じてアクセスを制限または制限できます。
一部のログサーバー/アグリゲーターソリューションでは、特定のデータ(ユーザーアカウントやマシンIPなど)への参照を含むエントリをユーザーが表示しないように制限できます。つまり、管理者が他の管理アクティビティを表示できるようにすることができますが、自分のアクティビティは表示できません。
通常、ログサーバー/アグリゲーター内にアラートを配置して、いずれかのマシンからのログの受信が停止した場合、または特定のしきい値を下回った場合にトリガーします。これは、ローカル管理者がログサーバーへのログの送信を妨げているかどうかを検出するのに役立ちます。アグリゲーター。
Syslogサーバー、SIEM、ログアグリゲーター、ELKスタックなど。さまざまな方法で探索できます。
侵害されたホスト上のログはすべて疑わしいものです。一元化されたロギングプラットフォーム、中央のsyslogサーバー/ splunk/logrhythm /何でも必要です。別の管理者とアカウントのセットを保持します。それが全体のアイデアです。
プラットフォームが準備できたら、自分のアクションまたは他の管理者のアクションを表示する権限を委任できます。特定のログソースと委任されたホストを読み取る権限を持っています。
攻撃者がマシンで高い権限を取得した場合、ログコントローラーはもちろんのこと、マシン全体は信頼されていませんです。
詳細は異なる場合がありますが、リモートログサーバーがここでの唯一のオプションです。ログをローカルに保存するよりも安全な方法でログを処理し、アクセス制御を管理できます。
最初のステップは、別のサーバーにログを送信することです。これにより、最初のサーバーが危険にさらされた後(したがって、ログが変更される可能性があります)、そのログサーバーにこれらのログエントリが含まれます。そして、このサーバーはよりしっかりと保護することができます(すべきです)。
それでも、someoneは、サーバーを更新できるようにする場合にのみ、そのサーバーを管理できる必要があります。
そのサーバーのログをさらに保護する方法:
thisこれを使用することを主張するとき、これはブロックチェーンテクノロジーを使用することを述べる方が売りになるかもしれません。
²または、ログ自体に機密性がない場合は、ログサーバーイベントをクリアテキストでプッシュすることもできます。「jdoeがログサーバーにログインしてrm -rf /
"
管理者からログを保護するいくつかの可能な方法:
Filter uidごとにrsyslogを使用してログを監査し、uidごとにファイルを作成します。次に、SELinuxを適用して任意のポリシーを実装できます。特に、1人の管理者が自分のログにアクセスできないようにすることができます。ここで提案するソリューションでは、制限的なポリシーがある場合に、独立した管理者チームがログサーバーのログにアクセスする必要がなくなります。
他の人が言ったように、ログは一元化されます。さらに、これらの集中ログサーバーへのアクセスは、ローカルアカウントでのみ実行されるものとします。
1つの解決策は、データダイオードを使用して、集中管理されたログコレクタサーバーへのアクセスを保護することです。さらに、保護を強化するために、特定の個々のユーザーアカウントを作成できます。