mTLS によるフリート監視

フリートのすべてのサーバーを、 ひとつの緑の画面 で見渡す。

軽量エージェントが相互 TLS でメトリクスとセキュリティ信号を送信します。Servers Sentinel は各ホストを採点し、いつものチャネルへ通知し、総当たり攻撃を始まった瞬間に検知します。

1 台目は無料。カード不要、1 行でインストール。

Windows と Linux の混在フリート向け

systemd + Windows サービスamd64 · arm64 · 386mTLS インジェストセルフホストまたはマネージド
01なぜ

報告の合間にフリートは見えなくなる

ダッシュボードが更新される頃には、インシデントは既に 1 時間前のもの。Servers Sentinel はその隙間を埋めます。

死角

ホストが報告を止めても、ユーザーが気づくまで誰も気づかない。カバレッジは画面を見ている人に依存すべきではありません。

アラート疲れ

ツールごとに受信箱があり、信号はメール・チャット・Webhook に散らばり、やがてすべて無視されます。

静かな総当たり

RDP や SSH のパスワード推測はログ確認で表面化するまで何時間も走ります。数秒で浮かび上がるべきです。

設定のドリフト

サーバーごとに設定したしきい値は時間とともにずれます。既定値はカスケードし、その上にホスト単位の上書きを重ねるべきです。

1 つのエージェント、1 つのコンソール、ホストごとに 1 つのスコア

Servers Sentinel はメトリクスをローカルで収集し、相互 TLS で送信し、1 つの健全性スコアと明確なアラートに凝縮します。グローバルテンプレートは各サーバーへカスケードし、どのホストも既定値を壊さずにキーを上書きできます。

02仕組み

インストールからアラートまで 4 ステップ

コンパイル不要、受信ポートの開放も不要。すべて TLS の送信方向で動作します。

  1. 01

    サーバーを追加

    パネルでホストを登録し、短命の登録トークン付きの 1 行インストールコマンドを取得します。

  2. 02

    インストーラーを実行

    スクリプトが OS とアーキテクチャを検出し、エージェントをサービスとして導入し、mTLS で登録します。

  3. 03

    報告を確認

    CPU・メモリ・ディスク・ネットワークが一定間隔で届きます。各ホストにライブの健全性スコアが付きます。

  4. 04

    アラートを振り分け

    ルールがメール・Telegram・Slack・Webhook に発火します。総当たりはエージェントで検知し即座に印を付けます。

03機能

コンソールができること

中核ループは今日から。セキュリティ・ディスク・データベースは差し込み可能なモジュールとして設計されています。

01

ライブメトリクス

ホストごとの CPU・メモリ・ディスク・ネットワークを時系列で保存し、一目で読めるスパークラインで描画します。

02

2 段階の設定

グローバルテンプレートが既定値を決め、各サーバーは必要なキーだけ上書き。上書きはカスケードし、決してフォークしません。

03

mTLS インジェスト

各エージェントはクライアント証明書を保持。インジェストは相互認証され、漏れたトークンだけでは何も開きません。

04

総当たり検知

エージェントが RDP と SSH の認証をローカルで監視し、主要な送信元 IP とともにアクティブな攻撃を報告します。

05

健全性スコア

各ホストを 0-100 の単一スコアに集約。数百台のフリートも要注意順に自ずと並びます。

06

マルチチャネル通知

メール・Telegram・Slack・Webhook。チャネルを追加し、テストを送り、ルールを振り分けます。

07

マルチテナントのチーム

ユーザー・チーム・ロール(閲覧者・オペレーター・管理者)が各顧客のフリートを 1 つのログインの内側で分離します。

08

クロスプラットフォームのエージェント

Linux の systemd ユニットと Windows サービスを 1 つのプロトコルで。amd64・arm64・386 に対応。

04料金

フリートに合わせて伸びる料金

1 台から無料で開始。ホスト数に応じて月払いまたは年払い。

Free

¥0/月
1 台
単一ホスト、またはコンソールの試用に。
  • 監視対象 1 台
  • ライブメトリクス + スコア
  • メール通知
  • 総当たり検知
  • チームロール

Solo

¥1,200/月
サーバーごと / 月
少数の本番ホスト向け。
  • 最大 5 台
  • すべての系列
  • メール + Telegram
  • 総当たり検知
  • チームロール

Team

人気
¥3,900/月
月額
オペレーターが複数いるフリート向け。
  • 最大 50 台
  • すべての通知チャネル
  • 総当たり検知
  • チーム + ロール
  • 設定テンプレート

Business

¥12,900/月
月額
マネージド運用・マルチテナント向け。
  • サーバー無制限
  • マルチテナント分離
  • 優先サポート
  • セルフホスト対応
  • 監査ログ

Pro を 14 日間無料で、カード登録なし

登録すればサーバー全体を監視できます。メトリクス履歴、稼働監視と API チェック、Telegram 通知、レポートまで。期間終了後も請求はありません。アカウントは Free に戻り、1 台のサーバー監視は継続します。

無料トライアルを開始
05利用シーン

サーバー群を本当に監視しなければならなくなるとき

サーバーが今どうなっているかを知らないことが、許容できるリスクでなくなる15の状況です。このうちのどれかにご自身の環境が当てはまるなら、その隙間はすでに存在しています。まだ何も請求されていないだけです。

fleetlast seen04:12nobody was told17 up1 unknown

サーバー群の監視が必要になるとき

最初のグループは、見過ごされてしまうものについてです。どれも怠慢の話ではありません。台数が、人が頭の中に置いておける数--多くのチームでは4台ほど--を超えたときに必ず起きることです。

  1. 01

    ホストが黙り込み、利用者から電話が来るまで誰も気づかない

    あるマシンが報告をやめます。ハイパーバイザーに再起動されたのかもしれませんし、経路を失ったのかもしれませんし、メモリを使い切ったのかもしれませんし、ラックを片付けていた誰かに電源を落とされただけかもしれません。それを知らせるものは何もありません。存在しないサーバーはエラーを出しませんし、沈黙は健全なサーバーが出すものとまったく同じだからです。

    問題のすべては、障害と電話のあいだの空白にあります。それはたいてい時間単位で測られ、見つけるのは決まっていちばん都合の悪い人であり、そのときにはもう問いは「何が壊れたか」ではなく「なぜ誰も知らなかったのか」に変わっています。

    • ホスト移行から二度と戻ってこなかった仮想マシン
    • パッケージ更新のあと静かに死んだエージェントやサービス
    • 夜のうちに回線が落ちた拠点
    • 誰か別の人が見ているはずだと全員が思い込んでいたマシン
  2. 02

    深夜3時にディスクが埋まり、データベースを道連れにする

    ディスクの枯渇は、あらゆる障害のなかで最も予測しやすいものです。ログは増え、バックアップが二重に書かれ、一時テーブルは片付けられず、空き容量の曲線は2週間前から同じ日付を指し続けています。

    そして復旧にいちばん費用がかかる障害でもあります。書き込みの途中で容量を失ったデータベースは、行儀よくは止まらないからです。80% の警告と 100% の呼び出しの差は、2分の掃除と昨夜のバックアップからの復元との差です。

  3. 03

    何かが何週間も劣化し続けたのち、ついに落ちる

    メモリリーク、コネクションプールの枯渇、日ごとに掃けるのが遅くなるキュー、あと1か月で切れる証明書--どれも「事象」ではありません。これらは傾きであり、傾きは、常に現在値しか見ない人には見えません。

    履歴がなければ比べる相手がありません。「このホストでメモリ 70% は普通か」という問いは、何かが「普通」を記録していなければ答えようがなく、しかもその記録は、誰かが尋ねようと思いつくより前から動いていなければなりません。

  4. 04

    Windows と Linux が混在し、全体を一望している人が誰もいない

    現実の環境はたいてい混在です。会計システムとファイル共有のための Windows サーバーが数台、サイトとデータベースのための Linux が数台、遠隔拠点にはもしかすると ARM の何かが。プラットフォームごとに固有の標準ツールがあり、互いに口をききません。

    そのため全体像は手作業で、その日の当番の頭の中で、サービスコンソールと SSH セッションとホスティング事業者の管理画面から組み立てられます。しかも組み立てられるのは、誰かが見に行ったときだけ--つまり、すでに何かが起きたあとです。

    • 片方はイベントビューアー、もう片方は journalctl、共通の時系列はなし
    • 同じしきい値がプラットフォームごとに別のことを意味する
    • 設計されたのではなく育ってしまったため、誰も標準化していない構成
  5. 05

    マシンが同時に複数の場所に置かれている

    オフィスに1台、ホスティング事業者に2台、あるクラウドに3台、誰も終わらせなかった移行のせいで別のクラウドに1台、そして今のチームが来る前に設置された拠点の1台。それぞれに固有のアドレス空間、固有のアクセス経路、固有の担当者があります。

    それらすべてをまたぐ単一のコンソールはありません。もともと1つのものとして買われていないからです。必要なのは、物理的にどこに置かれていようと、それらを1つの環境として扱う場所です。

db-01disk 96%email34chat61webhook88sms115four inboxes · one incidentalerts / week1 240read: few

信号は出ているのに、人に届かないとき

2つ目のグループは、「検知できた」と「誰かが実際に動いた」のあいだの距離についてです。痛手になったインシデントのほとんどは、その間ずっとログに見えていました。失敗したのは最後の数メートル、機械と人間のあいだです。

  1. 06

    ツールごとに受信箱があり、信号が散らばる

    あるシステムはメールを送り、別のものはチャットに投稿し、3つ目は Webhook を叩き、ホスティング事業者は SMS を送り、バックアップソフトは、設定して以来誰も開いていないフォルダーにレポートを置きます。

    何一つ突き合わされません。同じインシデントが4つの異なる名前で4か所に4件の通知を生み、それらが同じインシデントだと気づく仕事は、たまたま正しいウィンドウを見ていた人に降りかかります。

  2. 07

    アラート疲れ:すべてが鳴るので、何も鳴っていないのと同じになる

    調整されていない監視は絶え間なく通知します。夜間バッチ中の CPU の跳ね上がり、毎週越えているしきい値をまた越えたディスク、設計どおりに再起動しただけのサービス。人はこれらを無視してよいとすぐに学習しますし、その判断は--無視してはいけない日が来るまでは--正しいのです。

    いったんそのチャネルが読み手に「飛ばしてよい」と教えてしまえば、通知を増やすことは改善ではなく悪化です。有用な指標は、どれだけ検知したかではなく、どれだけが人に届き、その人が何かをしたかです。

    • チームの半分がミュートしているチャットチャンネル
    • アラートを誰も読まないフォルダーへ振り分けるメールルール
    • あとになって見つかった本物のインシデント--ずっとそこにあったチャネルの中で
  3. 08

    夜間も週末も8月も、当番がいない

    中小規模のチームは輪番を組んでいません。システムを知っている人は寝ているか、飛行機の中か、休暇中で、インシデントはそれに配慮しません。したがってすべては、実際に連絡がつく人--それを一切作っていない人も含めて--に理解できるものでなければなりません。

    そこから、アラートが何を書くべきかという厳しい要件が生まれます。「db-01 CPU 96%」は、db-01 にログインしたことのない人にとって午前3時には何も意味しません。何と並んで起きたのか、平常時はどうなのか--それが、復旧できるか電話を掛け回すかを分けます。

  4. 09

    マシンごとに設定したしきい値がばらばらになっていく

    どのサーバーも手作業で、別々の時期に、別々の人が、人を起こすに値する基準についての別々の考えで設定しました。2年経てば一致するマシンは2台とありません。なぜ一方が 85% で他方が 95% なのかを覚えている人はおらず、全部変えるということは全部を回るということです。

    環境に必要なのはそうではなく、どこにでも波及する既定値と、上書きとして見える形のホスト単位の例外です。そうすれば逸脱は、歴史上の偶然ではなく、誰かが見直せる意図的な判断になります。

  5. 10

    パスワード推測が、数週間後のログ確認でようやく浮かび上がる

    公開された RDP や SSH のポートは絶えず攻撃されていますが、当たってしまったログインは、ログの上ではほとんど通常のログインと同じ見た目をしています。手がかりはあります--失敗の増加、見慣れない送信元、新しい国からの史上初の成功ログイン--けれども、それは誰も毎日は読まないファイルの行としてしか存在しません。

    ですから検知は、四半期に一度人がやることではなく、機械がやることでなければなりません。重要なのは最初の試行から最初の成功までの窓であり、それはたいてい時間単位で測られます。

    • 誰もグラフにしなかったログイン失敗の急増
    • そのアカウントが一度も使ったことのない時間帯の成功ログイン
    • 複数のサーバーに同時に現れる同一の送信元アドレス
30 days2 incidents · both reportedthis month99.7%availabilityexported · signed

契約・監査・顧客が記録を求めてくるとき

3つ目のグループは、技術チームの外にいる誰かが答えを必要とする瞬間についてです。可用性、インシデント履歴、監視していたことの証拠は、記録として存在するか、まったく存在しないかのどちらかです。後から記憶で組み立て直すことはできません。

  1. 11

    SLA や顧客との契約が稼働率の証明を求める

    可用性がいったん合意文書に書かれれば、それは感触であることをやめ、毎月提出し、争われれば弁明し、毎回同じ方法で計算しなければならない数値になります。「知る限りでは動いていました」は測定ではありません。

    記録は逆方向にもあなたを守ります。可用性をめぐる争いの多くは障害が誰の責任かという話であり、顧客側の回線が落ちているあいだホストは健全だったと示す時系列は、どんな主張よりも早く議論を終わらせます。

    • 顧客に対して負っている月次の可用性の数値
    • 誰も測っていないしきい値によって発動する違約条項
    • 開始と終了が分単位で必要になるインシデント
  2. 12

    監査人や保険会社から、システムをどう監督しているかを問われる

    サイバー保険の申込書、取引先セキュリティ審査、決済データや個人データに関する規制は、いずれも同じことを言い換えて尋ねます。あなたのシステムが意図どおり動いていることをどう知っているのか、そして動いていないときにどうやって気づくのか。

    求められているのは製品名ではありません。対象期間を通じて監視が途切れなく行われていたこと、アラートが人の読む場所へ届いていたこと、そしてインシデントが記憶ではなく記録として残っていることの証拠です。

  3. 13

    1人の管理者が多くの顧客のサーバーを見ている

    マネージドサービス事業者、フリーランスのシステム管理者、小規模な IT 会社は、企業も事業者もネットワーク構成も異なる数十台のマシンを抱えています。顧客ごとに営業時間も、停止の許容度も、何を緊急とみなすかの感覚も違います。

    1台ずつ手で設定するやり方は規模に耐えませんし、顧客からの電話で初めて問題を知るやり方も同じです。こうした環境には、どこにでも適用される共通の基準、顧客が本当に異なる場合の顧客単位の例外、そしてすべてを一望できる1枚の壁が要ります。

  4. 14

    この環境について分かっていることが、すべて1人の頭の中にある

    どのマシンが重要か、そこでの平常の負荷はどれくらいか、どのアラートなら無視して安全か、あのしきい値をなぜ3月に上げたのか--どれもどこにも書かれていません。それはすべてを構築した人が抱えており、その人が去るときに一緒に去ります。

    引き継ぎはそこで発掘作業になり、新しい担当の最初の数か月は、1年前には完全に分かっていたことを再発見することに費やされます。人の外側に存在する履歴と設定だけが、それに対する防御です。

    • あらゆる設定の理由を持ったまま辞めていく同僚
    • ある数値が異常かどうかを誰も言えない休暇期間
    • 比較する基準線のないまま新しい業者へ引き渡される環境
  5. 15

    サーバー群を見張るものは、その全台への特権的アクセスを得る

    監視にはそれ自体のリスクがあります。あなたの全マシンからメトリクスを読むものは、定義上、あなたの全マシンに足場を持っています。しかも外部から到達可能です。そうでなければ意味がないからです。

    ですからサーバー群をどう見張るかという問いは、その経路についての問いでもあります。誰がそこに話しかけられるのか、双方はどんな身元を証明するのか、通信中のデータはどう扱われるのか、そして侵害されたコンソールは環境全体を明け渡してしまうのか。何かをどこかに入れる前に尋ねて当然の問いです。

06FAQ

よくある質問

本番サーバーで安全に動きますか?

本番サーバーで安全に動きますか?

はい。エージェントはローカルのメトリクスと自身の認証ログのみを読み、TLS で送信方向に接続します。受信ポートは開かず、攻撃的な機能もありません。

Windows と Linux の両方で動きますか?

Windows と Linux の両方で動きますか?

はい。1 つのプロトコルが Linux の systemd ユニットと Windows サービスを、amd64・arm64・386 で動かします。インストーラーがプラットフォームを検出します。

インジェストはどう保護されますか?

インジェストはどう保護されますか?

各エージェントはクライアント証明書で登録し、相互 TLS で送信します。盗まれた登録トークンは短命で、既に登録済みのホストになりすませません。

2 段階の設定はどう機能しますか?

2 段階の設定はどう機能しますか?

グローバルテンプレートを一度だけ設定します。各サーバーは個別のキーを上書きし、上書きは既定値を置き換えず上に重なるため、テンプレート変更は各ホストへ届きます。

セルフホストできますか?

セルフホストできますか?

はい。パネルは Traefik の背後で Postgres(TimescaleDB は任意)とともに docker-compose スタックとして提供されます。リポジトリのデプロイガイドを参照してください。

総当たり検知は何をカバーしますか?

総当たり検知は何をカバーしますか?

エージェントが RDP と SSH の認証をローカルで監視するため、パネルの更新前でも数秒でアクティブな攻撃と主要な送信元 IP を示します。

ユーザーが電話をかける前に利用できないサーバーを検出する

私の状況では、ユーザーが呼び出したときに仮想マシン、サービス、またはブランチ リンクが停止したことだけがわかります。移行またはアップグレードの後、ホストは夜間にデータの送信を停止する可能性があり、ハートビートと責任のある所有者が 1 人もいません。サーバーの可用性監視を設定して、ホストが失われた直後に信号を受信するにはどうすればよいですか?

私はServers Sentinel では、エージェントを systemd-unit または Windows サービスとしてインストールし、mTLS アウトバウンド チャネルに接続して、最新のテレメトリとホストのヘルス スコアを確認します。欠落データのルールを設定し、メール、電報、Slack、または Webhook に通知を送信して、テストのギャップを確認します。電子メール通知を備えた無料プランで 1 つのサーバーを維持できます。

私はServers Sentinel を使わず無料で blackbox_exporter/Prometheus または別のサイトから ping/TCP cron チェックを実行し、last_seen を保存し、Alertmanager 経由でアラートを送信します。外部のデッドマン スイッチを使用して監視自体を個別にチェックし、通常の再起動の遅延を設定し、ホストの所有者を文書化します。それ以外の場合、監視システムの損失はグリーン ステートとして表示されます。

ベースに障害が発生する前にディスクがいっぱいになるという警告

私のサーバーでは、ログ、バックアップ、一時テーブルが増加しており、夜間には空き領域がゼロに近づきます。この傾向は数週間にわたって見られましたが、ベースは記録の途中で停止する可能性があります。 90% という単一のしきい値では、小規模なボリュームにも大規模なボリュームにも十分ではありません。ディスクの監視と容量予測を設定するにはどうすればよいですか?

私はServers Sentinel を使用して、各ファイル システムの使用済み領域と空き領域を時系列として収集し、一般的なしきい値と特定のボリュームの個別のオーバーライドを設定し、重要な値になる前に通知を送信します。現在のパーセンテージの横にある増加率を確認し、Linux 上の i ノードを確認して、WAL/ログおよび緊急操作用に十分なマージンを残します。

私は無料で、node_exporter/windows_exporter を Prometheus と Alertmanager とともにインストールするか、cron/Task Scheduler 経由で df/Get-Volume を実行します。パーセンテージと絶対ギガバイトで同時に警告し、24 ~ 72 時間の期間に対して rate/predict_linear を追加し、logrotate/retention を構成し、非クリティカルなボリュームを人為的に埋めることでアラートをテストします。

傾向に基づいてサーバーの遅い劣化を特定する

私の状況では、メモリが 70% になっているか、キューが増加しているのがわかりますが、これが特定のホストにとって正常なのかどうかはわかりません。クリア イベントが 1 つも発生しないまま、メモリ リーク、接続プーリング、期限切れの TLS 証明書が数週間にわたって悪化します。サービスが失敗した場合、ベースラインはありません。傾向を監視し、劣化を早期に検出するにはどうすればよいですか?

私はServers Sentinel では、一連の CPU、メモリ、ディスク、ネットワークを保存し、ホストを自身の履歴と比較し、現在の状態を 0 ~ 100 のスコアにロールアップします。分間のピークに反応しないように条件の期間を設定し、証明書の期間またはアプリケーションの応答が重要な場合には個別の稼働時間/TLS/API チェックを作成します。

Prometheus、エクスポーター、Grafana を無料でデプロイし、ベースラインと持続可能な成長のためのアラートの記録ルールを設定し、blackbox_exporter で証明書を確認します。私は少なくとも数週間分のデータを保存し、展開/メンテナンスをグラフにマークし、関連するメトリクスに対してのみレート/導出を使用します。私は TSDB をサポートしており、自分自身もルールを定めています。

WindowsサーバーとLinuxサーバーの統合監視

私のフリートには、Windows Server、さまざまなディストリビューションの Linux、および ARM ホストが含まれています。現在、イベント ビューアー、journalctl、および hoster パネルを個別に確認しているため、共通の時間スケール、同じステータス、および単一の問題のリストはありません。クロスプラットフォームのサーバー監視を 1 つのパネルにまとめるにはどうすればよいですか?

私はServers Sentinel では、amd64、arm64、および 386 上の Windows サービスと systemd エージェントに 1 つのプロトコルを使用し、同じ基本メトリクスと同じヘルス スコアを取得します。プラットフォームの違いはオーバーライドに保持しますが、フリート全体をリスク別に分類し、エージェントの受信ポートを開かずにテレメトリを mTLS に渡します。

私は無料で、windows_exporter とnode_exporter を 1 つの Prometheus に結合し、ホスト/クライアント/OS ラベルを正規化し、共通の Grafana ダッシュボードを構築します。 Windows イベント転送と syslog/Loki を UTC でマッピングし、OS のさまざまなしきい値をコードとして記述し、ルールを移行せずにエクスポータを更新してもメトリクスの名前が変更されないことを確認します。

オフィス、クラウド、支店のサーバー監視

私のサーバーはオフィス、2 つのクラウド、ホスターとブランチの間に分散されており、NAT の背後にあり、共通のアドレス指定を持っていません。すべてのホストで受信ポートを開きたくはありませんが、サイトに関係なく可用性とリソースを単一のビューで確認したいと考えています。分散サーバーの監視を一元的に行うにはどうすればよいですか?

私はServers Sentinel を使用して、各ホストにエージェントをインストールします。発信接続自体を開始し、mTLS クライアント証明書によって認証されます。各マシンへの受信ルートを構築せずに、サイトと所有者のタグを割り当て、1 つのコンソールですべてのホストを確認し、ポイントごとのオーバーライドでルールをグローバルに設定します。

私は無料で、WireGuard サイトとポーリング エクスポータを中央の Prometheus に接続するか、外部にメトリクスを送信するremote_write/agents を使用します。 ACL をコレクタ アドレスのみに制限し、TLS 証明書で保護し、破損した場合はデータをバッファし、VPN 自体を監視します。ネットワークの設計とキーのローテーションは自分で行います。

異種通知チャネルの統合

私の状況では、1 つのシステムは電子メールを送信し、別のシステムは Telegram に書き込み、3 番目のシステムは Webhook を呼び出し、ホスティング者は SMS を送信します。あるインシデントは別の名前で表示され、どのメッセージが主要なメッセージであるのか誰も理解できません。監視通知を一元管理し、アラームを特定のサーバーおよびルールに関連付けるにはどうすればよいですか?

私はServers Sentinel を使用して、1 つのコンソールで電子メール、テレグラム、Slack、または Webhook チャネルを作成し、テストを送信し、必要なホストに従ってルールを送信します。 4 つの独立した文字からインシデントを収集するのではなく、オペレーターがメトリック、しきい値、および時間を確認できるように、単一の名前とホスト コンテキストを使用します。

私は無料で、Prometheus Alertmanager を 1 つの通知ゲートウェイにルーティングし、group_by、group_wait、repeat_interval、抑制を設定し、ソースに 1 つの Runbook へのリンクを残します。ラベルの重大度/サービス/所有者を正規化し、テスト アラートでルートを確認します。 SMS および外部プロバイダーは、無料ソフトウェアであっても料金が発生する場合があります。

警戒疲労を軽減する

私の監視では、短い CPU スパイク、スケジュールされた再起動、同じしきい値を超えるドライブが毎晩警告されます。チームはチャンネルを無効にしたため、実際の事件も未読のままです。アラート疲労を軽減し、実行可能なアラートだけを残すにはどうすればよいですか?

Servers Sentinel を使用して、グローバルしきい値、条件期間、基準が異なるホストの例外を設定し、重大度レベルをさまざまなチャネルにルーティングします。私はヘルス スコアを使用して優先順位を付け、ルールをテストし、未対応のアラートを確認します。

私は無料で、所有者と Runbook でアラートのカタログを管理し、Prometheus で使用し、Alertmanager でグループ化と抑制し、自動完了でスケジュールされた作業を沈黙して終了します。通知、確認応答、再試行の数を測定し、実用的でない信号を削除し、すべてのしきい値を単純に引き上げることによってノイズをマスクしません。

完全な勤務をしていない夜間に警報を発する

私には小規模なチームがあり、年中無休のオンコールがありません。夜間には、サーバーを構築したことがなく、「db-01 CPU 96%」が何を意味するのか知らない人が対応します。重要な信号はコンテキストと理解可能なアクションとともに到着する必要があり、非重要な信号は朝まで待つ必要があります。夜間監視アラートを設定するにはどうすればよいですか?

私はServers Sentinel では、重大度とチャネルを分離し、ホスト名にロール/クライアントを追加し、違反が継続した場合にのみルールを構成します。メッセージをテストで確認し、受信者の Webhook に Runbook へのリンクを残し、メトリック グラフ/健全性評価を使用して、担当者が一時的なピークと劣化を区別できるようにします。

無料で、Alertmanager ルーティング スケジュールを作成し、重要なイベントを利用可能なゲートウェイ経由で通話/チャットに送信し、残りを毎日のキューに送信します。私は 3 つのアクション、所有者、エスカレーション基準からなるランブックを作成し、ダッシュボード リンクを追加し、トレーニング アラートを定期的に発行します。無料通話チャンネルは選択したサービスによって異なります。

ホストごとの例外を含む統合監視しきい値

私のサーバーは別の人によってセットアップされました。ディスク警告は 80、85、または 95% で表示されますが、その理由はどこにも書かれていません。基本しきい値を一度変更したいのですが、データベース、ファイル サーバー、および小規模なシステム パーティションについては意識的な例外を維持したいと考えています。ドリフトを発生させずに監視パターンを管理するにはどうすればよいですか?

私はServers Sentinel では、グローバル構成テンプレートを指定し、特定のサーバー上で必要なキーのみをオーバーライドします。オーバーライドは、構成全体をコピーするのではなく、デフォルトの上にカスケードされます。この偏差を例外として捉え、全体のしきい値を一度変更し、どのホストが意図的に異なる値に留まっているかを確認します。

私は無料で、Prometheus ルールとインベントリ パラメーターを Git に保存し、Jsonnet/Ansible ルールを生成し、例外の理由と期限を含むレビューを要求します。 CI 構文チェック、デプロイされた構成の差分、およびオーバーライドに関するレポートを実行します。このような規律がなければ、空きスタックであってもすぐに手動ドリフトに戻ってしまいます。

RDP および SSH を介したブルート フォースの即時検出

私の状況では、毎週セキュリティ イベント ログと auth.log を確認すると、パスワードの推測が見つかるだけです。この時点までに、最初の一連の失敗から最終的にログインが成功するまでに数時間が経過しており、1 つの IP が複数のサーバーを攻撃する可能性がありました。攻撃が開始されたときに RDP/SSH ブルート フォースの通知を受け取るにはどうすればよいですか?

私はServers Sentinel を使用して、ローカル認証検出を有効にします。Windows または Linux 上のエージェントが RDP/SSH イベントを読み取り、最上位の IP ソースを使用してアクティブな攻撃を送信します。ルールをライブ チャネルにルーティングし、ホスト間で 1 つのソースを照合します。検出機能は、対象となる有料プランまたは試用プランで利用できます。

私はWazuh/Elastic または Loki で Windows 4625 と sshd の失敗したパスワードを無料で収集し、スライディング ウィンドウのsource_ip による相関関係を作成し、その後の成功した 4624/Accepted のアラートを作成します。 NTP 経由で時刻を同期し、IPv4/IPv6 を正規化し、テスト スキャナを除外します。フリー パスには別のコレクタとルールのサポートが必要です。

ディメンションごとの可用性と SLA の計算

私の状況では、顧客との契約には、たとえば月あたり 99.9% などの SLA が記載されていますが、現在、可用性は感情と電話によって評価されています。紛争の場合は、各ダウンタイムの開始、終了、理由、合意された作業の除外、および単一の公式が必要です。稼働時間の監視と SLA レポートを整理するにはどうすればよいですか?

私はServers Sentinel を使用して、外部ポイントから TCP/TLS/API チェックを作成し、結果の履歴を保存し、アプリケーションの利用不能状態をエージェントのテレメトリの欠落から分離します。 SLO を設定し、メンテナンスを記録し、期限付きの定期レポートを生成します。署名する前に、間隔、検査領域、除外ルールについてお客様に同意します。

私は無料で、管理されたサイトの外に blackbox_exporter と Prometheus をデプロイし、可用性を成功したプローブ/予想されるプローブとして考慮し、Alertmanager イベントを保存します。メンテナンスを別のログに記録し、UTC を同期して Grafana レポートを生成します。 1 つの検証ポイントではグローバルな可用性が証明されないため、必要に応じて独立したプローブを追加します。

監査のための継続的なモニタリングの証拠

私の状況では、監査人、保険会社、または顧客は、システムが期間中監視されていたこと、誰がアラートを受け取ったのか、どのインシデントが解決されたのかをどのようにして知るのかを尋ねてきました。前月を確認しないため、現在の緑色のダッシュボードだけでは十分ではありません。継続的なサーバー監視の証拠を準備するにはどうすればよいですか?

私はServers Sentinel を使用すると、メトリクス、稼働時間チェック、ルール設定、チャネル、イベントの履歴を保存し、適切なプランでの所有者とポリシーの変更の監査ログを使用します。正確な期間のレポートをアップロードし、配信テストを添付して、エージェントの mTLS ID を説明します。データの欠如は、標準的なものではなく、観察のギャップであることに注意します。

無料で、Prometheus/Loki/Wazuh を安全なサーバーに保存し、バックアップ、構成と承認は Git に、インシデントはチケット システムに保存します。私はカバレッジ、ギャップ、警告テスト、例外リストを毎月記録し、レポートに署名し、アクセスを制限します。閉鎖手順がなければ、器具自体がコントロールされている証拠にはなりません。

複数の顧客のサーバーを1人の管理者が監視

私は MSP または次期管理者として、さまざまな会社、プロバイダー、ネットワークのサーバーを監視しています。クライアントにはさまざまな時間、しきい値、連絡先がありますが、データとアクセス権を混在させることなく、1 つの問題キューが必要です。マルチテナントサーバーの監視を組織するにはどうすればよいですか?

私はServers Sentinel を使用して、フリートをチーム/テナントごとに分割し、閲覧者、オペレーター、管理者の役割を割り当て、クライアントを例外とする基本テンプレートを適用しました。すべてのホストをヘルス スコアで並べ替え、所有者に通知を送信し、分離と無制限のフリートが必要な場合はビジネス/セルフホスト オプションを使用します。

私は無料で、個別の Prometheus テナンシー/インスタンスをデプロイするか、厳密なラベルと ACL を使用して Grafana にデータを分離し、クライアント シークレットを別のコンテナーに保存します。インベントリから構成を生成し、テナント/所有者ごとに Alertmanager をルーティングし、クロスアクセスのブロックをテストします。安全なマルチテナントを実現するには、1 つの共有ダッシュボードよりも多くの作業が必要です。

公園の基準や設定についての知識を維持する

私の状況では、どのサーバーが重要か、どのような負荷が正常であるか、およびしきい値が変更された理由に関するすべての情報は、1 人の管理者の頭の中にあります。休暇や解雇が発生すると、新人は文脈なしに数字を見て、どの逸脱が危険なのかわかりません。監視履歴を転送可能な運用文書にするにはどうすればよいですか?

Servers Sentinel では、ロールと所有者によってホストに署名し、メトリクス シリーズ、グローバル テンプレート、および明示的なオーバーライドを保存し、チャネルを所有者に関連付けます。私は履歴をベースラインとして使用し、変更プロセスの横に非標準のしきい値の理由を文書化し、権限を譲渡する前に新しいオペレーターに表示のみの役割を与えます。

無料で、Git でインベントリと Runbook を管理し、ダッシュボード リンク、所有者、依存関係、各オーバーライドの根拠を追加し、プル リクエスト経由で変更を受け入れます。私は Grafana/Prometheus のプロビジョニングをコードとして保存し、デプロイ/メンテナンスをマークし、四半期に 1 回インシデントを別の従業員に転送します。組織的な実践がなければ、グラフィックス自体が知識を保持することはできません。

最小限の権限を持つ安全な監視エージェント

私の状況では、監視エージェントが各サーバーに常駐し、信頼チェーンの一部になることを理解しています。受信ポートを開いたり、永続登録トークンを渡したり、クラウド パネルにフリート全体で任意のコマンドを実行できる機能を与えたりしたくありません。モニタリング エージェントを評価して安全に展開するにはどうすればよいですか?

私はServers Sentinel では、相互 TLS アウトバウンド接続を使用します。各エージェントはクライアント証明書を受け取りますが、有効期間の短い接続トークンは、すでに発行された ID を置き換えません。サービス権限、収集されたメトリクスとログのリストを確認し、不要なアクションを無効にし、1 つのホストにパイロットを展開し、サーバーが削除されたときの証明書の失効を制御します。

無料で、node_exporter/windows_exporter を別の非特権アカウントにインストールし、localhost/VPN のみをリッスンし、コレクター セットを制限します。 TLS/mTLS またはネットワーク ACL でスクレイピングを保護し、パケットに署名し、バージョンをコミットし、更新をスキャンし、信頼できないソースから書き込むテキストファイル スクリプトを有効にしません。私は構成管理と監視を分けています。

07信頼

誰が作っているか、誰に支払うのか、エージェントはサーバー群で何ができるのか

本番のサーバー群に管理者権限で何かを配る前に、答えを知っておく価値のある三つの問いです。

01

誰が作っているか

Servers Sentinel を書いているのは Recovery Toolbox の主任サーバーセキュリティスペシャリスト Victor G. Bobrov です。システム開発とセキュリティで20年以上、Microsoft MCSD/MCDBA 認定。ヘルススコアの算出もアラートルールもこのサイトのドキュメントも彼の仕事であり、匿名のブランドではなく本人の名前で公開されています。 ドキュメント →

02

誰に支払うのか

提供元はブルガリア(EU)登記の File Master LLC です。Bulstat/VAT 180842207、オフィスはヴァルナ、電話とメールで連絡できます。決済は PayPro Global が merchant of record として処理します。利用規約、プライバシーポリシー、データ処理契約は要約ではなく全文を公開しています。 利用規約 · プライバシー · DPA

03

エージェントにできること・できないこと

エージェントはローカルのメトリクスと自分がいるホストの認証ログを読み、相互 TLS で外向きに送ります。受信ポートは開かず、リモートコマンドの経路も持ちません - 外部からサーバー上で何かを実行させることはできません。各エージェントはクライアント証明書で登録し、登録トークンは短命です。盗まれても、すでに登録済みのホストになりすますことはできません。パネル自体は docker-compose スタックとして自前のハードウェアで動かせます。 エージェントの導入 →

08リソース

リソース:監視、監視対象のプラットフォーム、そして周辺の標準

サーバー群の監視は独立した話題ではなく、監視するプラットフォーム、それ以前からある道具、サーバーを測る標準の間にあります。以下はそれぞれを定義している情報源です。

Recovery Toolbox / File Master LLC

Recovery Toolbox へのお問い合わせ

Recovery Toolbox と File Master LLC の連絡先、および同社の主任セキュリティスペシャリスト Victor G. Bobrov のプロフィール。

会社オフィス

File Master LLC は、Recovery Toolbox のオンラインサービスおよびソフトウェア製品を提供する法人です。

File Master LLC
Serena app., office C13
Golden Sands, Varna, 9007
ブルガリア、欧州連合
Bulstat/VAT
180842207

Recovery Toolbox について

File Master LLC は、破損したファイル・データベース・メール保存形式を修復するための Recovery Toolbox のオンラインサービスとソフトウェア製品を開発・サポートしています。当社は、破損データへのアクセスを回復する必要があるユーザー、IT 専門家、企業向けの実用的な復元ツールに注力しています。

ご意見・ご提案を歓迎します。ウェブサイトへのご意見は電子メールでお送りください: webmaster@recoverytoolbox.com

Victor G. Bobrov, server security specialist and author of Servers Sentinel
セキュリティスペシャリスト

Victor G. Bobrov

サーバーセキュリティスペシャリスト・システム開発とセキュリティで20年以上

Victor G. Bobrov は File Master LLC / Recovery Toolbox でセキュリティ開発を統括しています。Servers Sentinel がサーバー群の何を見張るか - ホストのメトリクスから導くヘルススコア、認証ログのブルートフォース、CIS 基準からの設定の逸脱、そして管理者が異常に気づく前に鳴るべきアラート - を設計しています。

  • サーバー群の監視
  • サーバー要塞化と CIS
  • アラートとインシデント対応
  • MCSD
  • MCDBA

Microsoft 認定資格

Microsoft Certified Solutions Developer - MCSD。Microsoft Certified Database Administrator - MCDBA。

MCSD MCDBA

Servers Sentinel を最初のサーバーに向ける

ホストを追加し、1 行を実行すれば、1 分で報告が始まります。1 台目は無料です。