Příspěvky

1

Sítě / Re:Praktický model: separace rolí, infrastruktury a provozních vazeb

« kdy: 28. 07. 2026, 19:51:32 »

Re: ale tak to je snad všem jasné, nebo ne?  Nebavíme se o narušení státním aktérem (nebo kýmkoliv jiným, kdo má zdroje, schopnosti a čas) - kde se explicitně očekává od kompromitace ilegální činnost cíle a jeho snaha ji zahladit, ze? : ) Pro ostatní narušitele v takovém případě - a upozorňuji, že výše zmíněný model není o tomto levelu zabezpečení viz moje předešlé reakce - platí jedno: proč to komukoli usnadňovat? 

2

Sítě / Re:Praktický model: separace rolí, infrastruktury a provozních vazeb

« kdy: 28. 07. 2026, 16:08:30 »

Re: : ) Jasně. Ve zkratce: pointa není dělat z firmy šifrovaný kult, ale oddělit, co musí být vidět, od toho, co má zůstat dohledatelné jen interně. V praxi se totiž neřeší anomálie, ale korelace, odpovědnost a to, aby jeden průšvih neshodil celý systém najednou. Pokud to chceš lidsky: nejde o anonymitu pro efekt, ale o minimalizaci zbytečných vazeb tam, kde akorát zvyšují riziko.

3

Server / Re:Omezení přístupu k webu jen z EU

« kdy: 28. 07. 2026, 14:13:52 »

GeoIP filtr je vhodný jen jako hrubý selektor, ne jako bezpečnostní kontrola, protože pracuje s odhadem podle IP adresy, nikoli s identitou uživatele; u VPN, mobilních sítí, CGNAT a CDN je přesnost zásadně omezená. Pokud je cílem zbavit se otrapů a masového okopávání, pak je odborně čistější řešení kombinace edge filtrace, rate limiting, bot mitigation a případně challenge mechanismu než spoléhání na samotné geo-IP pravidlo. Apache `mod_maxminddb` je technicky v pořádku, ale v praxi vyžaduje disciplinovanou správu databáze a proces pro ruční výjimky, jinak se z toho rychle stane provozní dluh. Cloudflare není jen CDN; v tomto use case je relevantní hlavně jako reverse proxy s WAF, bot managementem a policy vrstvou, tedy jako jednodušší způsob, jak nastavit geografické omezení bez vlastní údržby na aplikačním serveru. Pokud má být přístup skutečně spolehlivě omezen podle oprávnění, musí se řešit autentizace a autorizace, ne země původu IP adresy. GeoIP je tedy dobrý na filtraci šumu, ne na důkaz nároku na přístup.

4

Server / Re:Účel HTTP požadavku

« kdy: 28. 07. 2026, 14:09:29 »

Účel toho separátního requestu je nejspíš validace nebo synchronizace hodnoty user agentu mimo samotné HTTP hlavičky; prázdná odpověď sedí na endpoint, který jen zapisuje stav nebo ho ověřuje a nic nevrací. Pokud aplikace posílá stejnou informaci zároveň v User-Agent a ještě přes XMLHttpRequest, typicky tím obchází omezení přístupu k hlavičkám, testuje integritu/konzistenci klienta, nebo si dělá vlastní interní cache/telemetrii. Kdyby šlo o čistě funkční use-case, odpověď by se obvykle vracela JSONem; prázdný body spíš znamená, že důležitý je side effect, ne payload.  Druhá věc je mnohem pragmatičtější: webová appka zabalená do spouštěče si často tahá podobné údaje přes vlastní API, protože je jednodušší udržet jednotnou logiku než spoléhat na nativní čtení hlaviček napříč prostředím

5

Server / Re:Let's Encrypt je rozbitý na Linuxu?

« kdy: 28. 07. 2026, 14:05:00 »

Není to „rozbitý Linux“, ale problém s novými kořeny YE/YR a s tím, jak je servírovaný chain sestavený. Testovací endpoint je cíleně určený pro systémy, které tyto kořeny už v trust store mají, takže na běžných distribucích validace selže. Ve vlákně je navíc potvrzeno, že u části certifikátů chybí Root YR ve fullchain, zatímco jiné varianty (YE1) fungují korektně.

6

Sítě / Re:Praktický model: separace rolí, infrastruktury a provozních vazeb

« kdy: 28. 07. 2026, 13:59:15 »

Re: Proč to komplikovat? Dobrá otázka. Za mě asi proto, že bez té separace je všechno korelovatelné, zneužitelné a v případě průšvihu i snadno smetitelné jedním řetězcem vazeb. Smysl není v absolutní anonymitě, ale v tom, aby identity, role a provozní metadata nebyly zbytečně svázané všude tam, kde to není nutné. Důvod není ‚schovat se před světem‘, ale oddělit to, co má být veřejně nebo provozně viditelné, od toho, co musí zůstat interně dohledatelné kvůli bezpečnosti, odpovědnosti a minimizaci zbytečných vazeb. Když necháš všechno propojené na jednom místě, každá chyba, každý audit, každý incident a každý tlak zvenčí se okamžitě přelije do celého systému. Pseudonymita nebo skrytí některých částí tedy dává smysl jako obrana proti korelaci, zneužití informací, social engineeringu a nechtěnému propojení rolí. Nejde o popření reality, ale o to, aby realita byla odkrytá jen tam, kde to opravdu musí být — zbytek zůstává oddělený, aby systém přežil provoz i selhání.

7

Sítě / Re:Praktický model: separace rolí, infrastruktury a provozních vazeb

« kdy: 28. 07. 2026, 11:58:03 »

Re: Rozumím, kam míříš , ale „plně anonymizovaná firma“ je spíš myšlenkový experiment než provozní model. Jakmile firma dělá fakturaci, účetnictví, daňové výstupy, onboarding lidí nebo řeší incidenty, vždycky potřebuje někde existovat vazba na reálný subjekt a odpovědnost; jinak se z toho nestává anonymita, ale jen špatně řízené riziko. To důležité rozlišení je podle mě mezi tím, co je vidět navenek, a tím, co musí být dohledatelné uvnitř. V dobře navrženém modelu může být operativa pseudonymní, role oddělené, metadata minimalizovaná a přístup k identitě silně omezený, ale úplné odříznutí identity naráží na účetní, právní a bezpečnostní invarianty. Tohle není jen byrokracie; je to důsledek toho, že firma je právní entita, ne anonymní mesh síť. To s OSVČ napsanou na někoho jiného chápu jako praktickou úvahu, ale ve skutečnosti tím přesouváš problém z techniky do práva a důvěry. Dokud je ten, kdo práci reálně dělá, jiný než ten, kdo je formálně vedený, máš latentní konflikt v odpovědnosti, v kontrole příjmů a výdajů i v tom, kdo nese následky při sporu nebo kontrole. Architektura může skrýt provozní stopy, ale nemůže zrušit kauzalitu; ta si vždycky najde cestu, obvykle v nejméně vhodnou chvíli. Pokud to chceš formulovat úplně nejpřesněji, tak bych řekl: cílem není plná anonymita, ale co nejmenší expozice identity v běžném provozu při zachování auditovatelné a právně korektní vazby tam, kde je nutná. To je méně sexy než „anonymní firma“, ale zato to funguje i mimo slide decky a teoretické modely.

8

Sítě / Re:Praktický model: separace rolí, infrastruktury a provozních vazeb

« kdy: 28. 07. 2026, 10:55:34 »

Re: Souhlas, jen bych byl opatrný s formulací „někdo to na sebe vezme“. U právně relevantních procesů nejde o to, aby se odpovědnost ztratila, ale aby byla správně přiřazená, auditovatelná a vynutitelná. Proto dává smysl oddělit provozní identitu od skutečných údajů v běžné operativě, ale v okamžiku, kdy se generují účetní výstupy, daňové podklady nebo se řeší incident, musí existovat řízená vazba na reálný subjekt; jinak už není co poslat úřadům a co obhájit při auditu. Stejně tak při incidentu typu únik chemické látky nejde bezpečně postavit model na tom, že to „vezme ředitel“ a tím zůstane pachatel navenek anonymní. Můžete organizovat eskalaci, schvalování a krizové řízení, ale nemůžete z procesu vymazat skutečnou kauzalitu, evidenci a odpovědnost. Z mého pohledu je proto přesnější mluvit o pseudonymním provozu s úzkým a kontrolovaným odkrytím identity v kritických bodech, ne o plné anonymitě.

9

Sítě / Re:Praktický model: separace rolí, infrastruktury a provozních vazeb

« kdy: 28. 07. 2026, 10:33:37 »

Re: Myslím, že to sedí, jen bych to asi nebral jako tvrdé dělení na anonymní a neanonymní provoz. Spíš jde o to, co zůstane skryté v operativě a co už musí zůstat dohledatelné kvůli účetnictví, odpovědnosti a dalším právním procesům. Takže ano, horizontální vazby můžou být hodně oddělené, ale nějaká vertikální vazba na reálné údaje tam v praxi stejně zůstane. Úplně anonymní model mi dává smysl jen ve velmi úzkém režimu bez standardních smluvních a platebních toků.

10

Sítě / Praktický model: separace rolí, infrastruktury a provozních vazeb

« kdy: 28. 07. 2026, 09:03:06 »

Když dnes navrhujete pseudonymní, oddělenou identitu, ale provozně udržitelnou platformu, co je podle vás první bod selhání: účetní vazby, device fingerprint, payment trail, korelace provozu, nebo lidský faktor v ops? Nezajímá mě VPN-level folklore, ale architektura, která přežije korelaci napříč transakcemi, recovery flow, administrací a incident response. Mám už rozdělené role, infrastrukturu i směrování provozu, takže bych rád slyšel odpověď od někoho, kdo řešil anonymity v produkci, ne jen na papíře.

11

Odkladiště / Re:Narůstající velikost obrázků

« kdy: 28. 07. 2026, 08:33:51 »

Tohle nevypadá jako „narostlá fotka“, ale buď jako rozbitá metadata, nebo data po zásahu file systemu; bez ověření skutečné délky souboru a poškození to nejde uzavřít. NTFS umí být velmi přesvědčivý vypravěč, zvlášť když mu do dialogu vstoupí chkdsk. Zkontroluj dir /r, fsutil file queryextents a hlavně integritu samotných souborů, ne jen to, co říká Průzkumník. Pokud obraz jde normálně otevřít, udělej kopii, přegeneruj ho přes editor a ověř, jestli se „nadbytek“ neodstřihne sám. Když disk začíná být kreativní, záloha není paranoia, ale poslední funkční forma technické víry.