Wat een toegangsregel op hostnaam op elke netwerklaag kan betekenen
Een servicenaam kan worden afgedwongen op DNS-, browser-, proxy- of firewallsniveau. Kies de laag die de identiteit ziet die u wilt besturen.
Drie mensen vragen hetzelfde met dezelfde woorden: de toegang tot één servicenaam blokkeren. De een bedoelt dat een browser de site niet mag openen, de ander dat een desktop-spraakclient zijn server niet mag bereiken, en de derde dat een groep aannemers een bepaalde interne applicatie niet mag gebruiken. De zin is identiek, en de handhavingsmechanismen hebben bijna niets gemeen.
Kies de laag op basis van de identificatie die zij werkelijk kan zien, en daarna op basis van de clients die zij dekt. Beginnen bij een firewallcommando dat u al kent, is hoe regels uiteindelijk niets blokkeren, of te veel blokkeren.
Een naam is geen identiteit die elke laag kan controleren
Netfilter en vergelijkbare packetfilters zien adressen, protocollen en poorten. Zij zien geen hostnamen, en tegen de tijd dat een pakket hen bereikt, is de naam al opgelost. Een regel die tegen een adres is geschreven, is een regel over dat adres, ongeacht welke naam een gebruiker typte om het te bereiken.
DNS-beleid zit eerder in het pad en ziet de query, dat een ander object is dan de verbinding die volgt. Het beheert de antwoorden die een gecontroleerde resolver teruggeeft, niet verbindingen die al open waren, en niet clients die zijn ingesteld om die resolver te omzeilen. Een opgelost adres kan ook veranderen tussen de beleidscontrole en het volgende verzoek, daarom is een DNS-antwoord geen duurzame autorisatieverklaring.
Hogere lagen zien meer context en dekken minder clients. Die ruil is het hele onderwerp, en hij verklaart waarom geen enkele rij van de tabel ooit het juiste antwoord is. Kies de rij die de identificatie ziet waarover uw beleid werkelijk gaat. Accepteer dan de dekking die die rij impliceert.
Wat elke laag kan identificeren
Lees de tabel van de middelste kolom naar buiten: de identificatie die een laag kan zien, bepaalt het beleid dat zij eerlijk kan handhaven.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
Een laag hoort alleen in het beleid wanneer de identificatie die zij ziet overeenkomt met de identificatie die u bestuurt. De tabel verklaart ook waarom een regel die op de ene laag is geschreven, zelden naar een andere overgaat zonder opnieuw te beslissen wat zij beschermt.
Waar de voor de hand liggende regel faalt
Een adresregel is precies goed voor een dienst met een toegewijd adres dat u beheert, en dat eigendom hoort in het beleid te worden geschreven. Hij is precies verkeerd voor alles achter een gedeeld contentbezorgadres, waar dezelfde regel ongerelateerde diensten raakt en een vernieuwd DNS-antwoord de regel niet in hostnaamautorisatie verandert.
Een beleid voor een beheerde browser drukt een webbeperking directer uit dan een gekopieerde adressenlijst, maar het geldt voor de browsers en profielen die het beheersysteem bestuurt.
Die browserregel doet niets aan een spraakclient die UDP naar een andere host stuurt, en de patronen ervan worden bepaald door dat product, niet door wildcardconventies die elders zijn geleend. Een CONNECT-proxy ontvangt ook een host en poort voor een getunneld verzoek, en kan het pad binnen de versleutelde sessie niet lezen. Ontwerp de regel rond wat het protocol blootlegt. Schrijf dan op wat zij onbedekt laat, want die leemte is waar het volgende verzoek vandaan komt.
Kies op basis van de clients, niet van het commando
Vraag welke clients het beleid moet dekken en welke het mag missen. Een beleid voor een beheerde browser dekt wat het beheersysteem bereikt en stopt bij de browsergrens. Een resolverbeleid dekt alles wat uw resolver gebruikt, een bredere verzameling, en het faalt open voor iedereen die dat niet doet.
Voor een dienst die u beheert, is autorisatie in de applicatie sterker dan welke netwerkgrens ook, omdat zij het account volgt en niet het pad. Een VPN-route is bereikbaarheid en niets meer: een pakket naar een dienst kunnen sturen is geen toestemming om hem te gebruiken. Waar de identificatie die ertoe doet een gebruiker of een kanaalmachtiging is, handhaaf die daar en behandel de netwerkregel als een tweede laag.
Schrijf de regel in termen van de bron
Een verdedigbaar beleid noemt de bron, de identiteiten, de applicaties binnen het bereik en het pad dat hen draagt, inclusief beide adresfamilies in gebruik. Het vermeldt ook wat er gebeurt met gedeelde infrastructuur die de regel terloops raakt.
Die formulering levert een beslissing op die iemand later kan auditen. Een regel die met het adres van vandaag wordt gerechtvaardigd, levert een incident op de eerste keer dat het adres verandert, en niemand zal kunnen uitleggen waarom de blokkade ooit juist was.