Zgjedhja e provave HTTP: regjistrat e portës apo regjistrat e aplikacionit

Monitorimi i uebit fillon me një qëllim, jo me një pikë kapjeje. Numërimi i klientëve aktivë, matja e një thirrjeje API dhe leximi i trupave të mesazheve kërkojnë secili prova të ndryshme dhe vendime privatësie të ndryshme. Një portë që përcjell HTTPS të mbrojtur sheh lidhjet, jo përmbajtjen e faqes. Zgjedhja e shtresës së gabuar jep të dhëna që duken të pasura dhe nuk përgjigjen asgjë.

Emërtoni pyetjen përpara burimit të të dhënave

Filloni me vendimin operativ që të dhënat duhet të mbështesin. Pyetjet e disponueshmërisë kanë nevojë për numërime dhe kohë, pyetjet e kërkesave kanë nevojë për shtigje dhe kode statusi, dhe pyetjet e përmbajtjes kanë nevojë për trupa mesazhesh. Çdo hap nga brenda shton ndjeshmëri dhe kompleksitet inxhinierik. Kërkoni nga pronari i shërbimit dhe pronari i sigurisë të miratojnë audiencën, qëllimin dhe trajtimin përpara se të fillojë mbledhja, sepse operimi i tunelit nuk është ai vendim.

Shkruani pyetjen në një fjali dhe mbajeni pranë planit të mbledhjes. Është i vetmi kontroll i besueshëm i fushëveprimit.

Çfarë mund dhe çfarë nuk mund të tregojë porta

Një portë që përcjell HTTPS të mbrojtur siç duhet sheh zakonisht adresa, porta dhe vëllime, jo rreshta kërkese ose trupa.

conntrack -L -d 203.0.113.10 | head
tcpdump -ni vpn0 -c 20 'tcp port 443'

Lista conntrack tregon rrjedhat dhe përkthimet, dhe kapja e shkurtër tregon paketat pa përmbajtje aplikacioni të lexueshme. Kjo mjafton për t'u përgjigjur nëse trafiku rrjedh, sa dhe midis cilave pika fundore. Nuk është një listë URL-sh, dhe një proxy CONNECT i zakonshëm përcjell shkëmbimin e kriptuar pa përfunduar TLS-in e aplikacionit. Kur dikush premton shtigje kërkese nga ai pozicion, pyesni cili komponent dekripton dhe nën besimin e kujt.

Regjistrat e aplikacionit përgjigjen shumicës së pyetjeve të kërkesave

Për një aplikacion që operoni, regjistrimi i tij i mbështetur zakonisht i përgjigjet pyetjes në nivel kërkese pa dekriptuar lidhjet e të tjerëve.

curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" https://app.example.com/health
tail -n 5 /var/log/nginx/access.log

Kërkesa e shëndetit mat disponueshmërinë nga pozicioni i një klienti, dhe regjistri i hyrjes shënon fushat që serveri ka zgjedhur tashmë t'i mbajë. Zgjidhni fushat që i nevojiten detyrës dhe lini pjesën tjetër jashtë, sepse edhe një URL mund të mbajë parametra të ndjeshëm. Një rresht regjistri është provë për atë shërbim, jo për çdo shërbim tjetër ku përdoruesi arriti përmes tunelit. Mbajtja e mbledhjes e ngushtë e mban të vogël edhe pyetjen e ruajtjes, prandaj caktoni një dritare më të shkurtër se eksperimenti mendor që prodhoi kërkesën.

Ndërhyrja është një dizajn besimi i veçantë

Nëse inspektimi në nivel mesazhi është vërtet i nevojshëm, ndërhyrja TLS krijon një pikë fundore të besuar të re dhe një marrëveshje besimi klienti që duhet shpërndarë dhe mirëmbajtur. Aplikacionet që fiksojnë certifikatat do të thyhen, dhe operatori tani mban çelësa privatë, mbrojtja e të cilëve vlen sa çdo çelës serveri. Të bësh mbledhjen të funksionojë duke dobësuar validimin e certifikatave, ose duke rregulluar një aplikacion që fikson certifikatat e veta, shkëmben një kontroll sigurie me një rresht regjistri. Preferoni një dizajn inspektimi të dokumentuar, shpërndarja e besimit të të cilit tashmë menaxhohet, dhe mbani çelësin privat të autoritetit jashtë çdo gjëje të përbashkët.

Në fund të dritares së mbledhjes, hiqni konfigurimin dhe materialin e tij të besimit përmes pronarëve të tyre, dhe asgjësoni provat e mbajtura sipas politikës së rënë dakord. Informacioni i besueshëm i mjaftueshëm për qëllimin e deklaruar është kriteri i suksesit, jo kapja më e madhe e mundshme.