Jak bezpečně monitorovat databázové servery
Monitoring databáze se dělá jinak než monitoring webu. Ve většině případů by databáze neměla být dostupná z veřejného internetu vůbec. Pokud veřejně dostupná je, umí nsmon kontrolovat její TCP port. V praxi ale často dává větší smysl nechat databázi privátní a vystavit úzký HTTPS health endpoint, který zevnitř aplikace ověří připojení i jednoduchý dotaz do databáze.
Co by měl monitoring databáze skutečně dokazovat
Otevřený TCP port dokazuje jen to, že na daném portu někdo poslouchá. Neříká nic o tom, zda databáze přijímá spojení korektně, funguje autentizace, nebo zda lze provést smysluplný dotaz. Proto je raw port monitoring užitečný, ale omezený.
U produkčních systémů bývá bezpečnější ponechat PostgreSQL, MySQL nebo Redis mimo veřejný internet a validovat jejich zdraví nepřímo přes aplikaci nebo dedikovaný health endpoint. Dostanete tím silnější signál a zároveň zbytečně neotevíráte citlivou službu ven.
Typické scénáře databázového monitoringu
Databáze je záměrně veřejně dostupná
Pokud je databázový port z veřejného internetu skutečně dosažitelný, TCP check vám řekne, zda listener na portu 5432, 3306 nebo 6379 stále přijímá spojení.
Databáze má zůstat privátní
Pak obvykle nechcete, aby se jí dotýkaly veřejné sondy přímo. Bezpečnější je ověřovat zdraví databáze přes webovou aplikaci nebo úzký health endpoint.
Potřebujete silnější signál než otevřený port
Malý dotaz jako `SELECT 1` nebo načtení metadat dokáže víc než samotná dosažitelnost. Potvrdí, že aplikace se opravdu připojí, autentizuje a dostane smysluplnou odpověď.
Chcete jedním monitorem pokrýt celou cestu
HTTPS health endpoint může potvrdit, že dohromady funguje DNS, TLS, webová aplikace i samotná databázová závislost.
Doporučený přístup k monitoringu
Nechte databázi privátní, pokud to jde
U většiny produkčních systémů není přímé vystavení PostgreSQL, MySQL nebo Redis do internetu best practice. Přístup omezte na síťové vrstvě a databázi neberte jako veřejný endpoint.
TCP port check použijte jen tam, kde je veřejný přístup záměrný
Pokud je databáze opravdu dosažitelná z internetu, nsmon umí ověřit, že TCP port stále přijímá spojení.
Pro reálnou validaci preferujte HTTPS health endpoint
Vytvořte úzký endpoint, který otevře spojení do databáze, spustí jednoduchý dotaz a vrátí stabilní marker jen tehdy, když je závislost zdravá.
V nsmonu hlídejte status i body match
HTTPS check s očekávaným statusem a textovým markerem ověří aplikaci i databázi společně, ne jen jeden surový port.
Jak o tom přemýšlet v praxi
U databází často dává smysl kombinace dvou různých typů kontrol:
Kontrola 1 TCP 5432 je dosažitelný Volitelný direct port check Kontrola 2 HTTPS /health/db -> 200 OK Aplikační validace databáze Kontrola 3 Body obsahuje "db_ok" Stabilní success marker
TCP check
Hodí se tam, kde je databázový port záměrně vystavený a chcete vědět, zda je listener dosažitelný z internetu.
HTTPS health check
Bývá hodnotnější, protože potvrzuje, že aplikace se do databáze skutečně připojí správnými kredenciály a po reálné síťové cestě.
Body match
Stabilní marker jako `db_ok` snižuje nejednoznačnost a nenechá za úspěch považovat libovolnou `200 OK` stránku.
Kombinovaný monitoring
Spojení obou vrstev pomůže odlišit prostou dosažitelnost portu od skutečného zdraví databázové závislosti.
Proč samotný port nestačí
Databázový proces může mít port stále otevřený, i když je rozbitá autentizace, vyčerpaný pool, špatná práva nebo selhává konkrétní query path. Zelený TCP port proto není důkaz, že je databáze zdravá pro reálný provoz.
Nejsilnější signál obvykle dává malý aplikační endpoint, který provede kontrolovaný dotaz a vrátí explicitní success marker jen tehdy, když tento dotaz uspěje.
Direct TCP check vs HTTPS database health endpoint
| Téma | TCP port check | HTTPS health endpoint |
|---|---|---|
| Co dokazuje | Že listener přijímá TCP spojení na daném portu. | Že aplikace databázi dosáhne, autentizuje se, provede dotaz a vrátí validní odpověď. |
| Bezpečnostní dopad | Vyžaduje veřejně dosažitelný databázový port, pokud se kontroluje z veřejných sond. | Databáze může zůstat privátní a monitoring přesto ověří její závislost. |
| Hloubka validace | Nižší. Hodí se jen pro základní dosažitelnost. | Vyšší. Lépe odpovídá reálné aplikační cestě. |
Best practices pro monitoring webu z tohoto endpointu udělají ještě silnější signál.
Pokud health endpoint vystavíte přes HTTPS, kombinujte expected status a body match, abyste nevalidovali jen port, ale skutečnou funkčnost.
Přečíst best practices pro monitoring webu →Příklady z praxe
PostgreSQL za aplikací
Často je nejbezpečnější pattern HTTPS endpoint, který provede `SELECT 1` a vrátí `db_ok` jen při úspěchu.
MySQL u legacy služby
Pokud je port veřejně dostupný záměrně, TCP check na 3306 dá základní signál a aplikační endpoint přidá hlubší jistotu.
Redis jako kritická závislost
Úzký aplikační endpoint může potvrdit, že aplikace zvládne lehký read nebo write, místo aby se Redis vystavoval přímo do internetu.
Admin zapomene, že otevřený port nestačí
Port zůstává zelený, ale aplikace padá kvůli credentials, migracím nebo oprávněním. Právě tady HTTPS health endpoint přináší větší hodnotu.
Důležitá omezení
- ● TCP port check neprokáže, že funguje autentizace, oprávnění ani skutečné SQL dotazy.
- ● Vystavovat databázi do internetu jen kvůli monitoringu obvykle není dobrý bezpečnostní trade-off.
- ● Health endpoint má být úzký a stabilní, aby se z monitoringu nestala zbytečně těžká syntetická zátěž.
- ● Odpověď by měla vracet jen bezpečný success marker, ne interní detaily databáze.
Co lidé zkoušejí ručně
nc -vz db.example.com 5432 Ukáže, zda je PostgreSQL listener dosažitelný z vaší aktuální sítě.
nc -vz db.example.com 3306 Rychlý způsob, jak zkontrolovat základní dosažitelnost MySQL portu.
curl -fsS https://app.example.com/health/db Je blíž realitě, protože validuje dohromady aplikaci i databázi.
Minimalistické ukázky health endpointu
<?php
$pdo = new PDO(getenv('DB_DSN'), getenv('DB_USER'), getenv('DB_PASS'));
$stmt = $pdo->query('SELECT 1');
if ($stmt && $stmt->fetchColumn() == 1) {
header('Content-Type: text/plain');
echo 'db_ok';
exit;
}
http_response_code(503);
echo 'db_fail';Odpověď držte záměrně malou. nsmon pak může hlídat HTTP 200 a textový marker jako `db_ok`.
from flask import Flask, Response
import os
import psycopg
app = Flask(__name__)
@app.get("/health/db")
def db_health():
with psycopg.connect(os.environ["DATABASE_URL"]) as conn:
with conn.cursor() as cur:
cur.execute("SELECT 1")
ok = cur.fetchone()[0] == 1
return Response("db_ok" if ok else "db_fail", status=200 if ok else 503, mimetype="text/plain")Stejný princip funguje i v jiných frameworcích: připojit se, udělat lehký dotaz, vrátit stabilní marker a nezveřejňovat interní detaily.
Časté dotazy
Monitorujte databáze tak, aby to odpovídalo realitě produkce.
V nsmonu můžete hlídat veřejné TCP porty tam, kde to dává smysl, nebo ověřovat silnější aplikační cestu přes HTTPS health endpoint, který potvrdí, že se vaše aplikace do databáze skutečně dostane. Vytvořte si účet zdarma a nastavte monitoring, který je bezpečnější i užitečnější.