VPN-kirjautumishälytykset: minkä tapahtuman pitäisi oikeastaan laukaista ne?
Onnistunut todennus, muodostettu tunneli ja RADIUS accounting Start ovat kolme eri väitettä. Valitse se, jonka perusteella vastaanottajasi voi toimia, ja korreloi ne sitten.
Onnistunut todennus, muodostettu tunneli ja RADIUS accounting Start ovat kolme eri väitettä, ja kirjautumissähköposti tarkoittaa jotain vasta, kun valitset niistä yhden. Useimmat VPN-hälytysten suunnittelut sekoittavat kaikki kolme ja tuottavat postilaatikon, johon kukaan ei luota. Päätös riippuu siitä, kuka hälytyksen lukee ja mitä hän voi tehdä seuraavien viiden minuutin aikana. Jos sen tekee väärin, hälytyksestä tulee kohinaa, joka kätkee ainoan tapahtuman, jota tarvitsit.
Kolme kysymystä ratkaisee laukaisimen
Kysy, kuka sen saa, mitä hän tekee ja kuinka nopeasti toiminnon on tapahduttava. Tunnusten väärinkäyttöä seuraava turvatiimi haluaa yhdestä tilistä epäonnistumisen ja sitten onnistumisen kuvion minuuteissa. Kapasiteettia seuraava operatiivinen tiimi haluaa istunnon keston ja katkaisusyyt, ei kirjautumisia. Tukipalvelu haluaa istunnon identiteetin, jotta se voi yhdistää sen tikettiin.
Nämä vastaukset osoittavat eri tapahtumiin, eikä mikään yksittäinen sääntö tyydytä kaikkia kolmea. Jos vastaanottajan toiminto on «soita käyttäjälle», todennus riittää. Jos toiminto on «vapauta lisenssi» tai «varmista, että tunneli kuljetti liikennettä», vain muodostus tai accounting Start kelpaa. Jos toiminto on «laskuta aika», tarvitset Stop-tietueita kirjautumisen sijaan.
Kirjoita vastaus yhdeksi lauseeksi ennen kuin määrität mitään. «Tämä sähköposti kertoo päivystävälle insinöörille, että tili X avasi tunnelin verkosta Y hetkellä Z, jotta hän voi tarkistaa, käytettiinkö huoltokatkoa.» Jos et pysty täyttämään jokaista kohtaa, laukaisinta ei ole vielä valittu.
Sovita tapahtuma väitteeseen, jonka esität
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Taulukko kätkee riippuvuuden: jokainen rivi on luotettava vain, jos yhdyskäytävä lähettää sen luotettavasti ja kerääjäsi säilyttää tarvitsemasi kentän. Lue tapahtuman määritelmä täsmälleen siltä versiolta, jota ajat, koska nimi «istunto muodostettu» muuttuu versioiden välillä ja merkitys muuttuu useammin kuin nimi. Kun määritelmä on epämääräinen, pyydä istunnon kaappaus sen sijaan, että arvaisit tunnisteen perusteella.
Access-Acceptin pitäminen kaiken sen jälkeisen valmistumisena on yleisin virhe. Se on tuomio tunnuksista, ei istunto. Peilivirhe on lukea käytäntövastaavuus todisteeksi valtuutuksesta, kun sääntö voi täsmätä ja seuraava vaihe voi silti epäonnistua.
Yksi istunto, yksi ilmoitus
Yksi tili, useita laitteita, uudelleenlähetykset ja uudelleenyhdistämiset: sähköposti jokaista tapahtumaa kohden on väärä molempiin suuntiin, monistaen yhden istunnon ja jakaen toisen. Avaa ilmoitus yhdyskäytävästä plus istunnon tunnisteesta ja käsittele tilin nimeä attribuuttina, ei avaimena. Käyttäjällä, jolla on kannettava ja puhelin, voi olla kaksi tunnelia yhtä aikaa, ja molemmat ansaitsevat oman rivinsä.
Uudelleenlähetetyt kirjanpitotietueet ovat normaaleja, joten poista kaksoiskappaleet istunnon tunnuksen ja aikaleiman perusteella ennen viestin renderöintiä. Saman laitteen peräkkäiset istunnot pitäisi pitää erillään, ja huoltokatkon aikana tapahtuva uudelleenyhdistäminen pitäisi pitää näkyvänä sen sijaan, että se sulautuisi edelliseen. Jos kerääjäsi kirjoittaa aikaleimat uudelleen vastaanotossa, poista kaksoiskappaleet alkuperäisen tietueen kentistä, ei tallennetuista.
Puuttuva Stop-tietue on epävarmuutta, ei pysyvä istunto. Yhdyskäytävän uudelleenkäynnistykset, kerääjän katkokset ja UDP-häviö jättävät kaikki aukkoja, joten hälytys tarvitsee täsmäytyspolun, joka kysyy elävien istuntojen taulukkoa ennen kuin kukaan päättelee, että tunneli on yhä pystyssä.
Pidä auditointi ja ilmoittaminen erillään
Auditointivirralla ja hälytysvirralla on eri tehtävät. Säilytä raakatietueet, mukaan lukien tili, yhdyskäytävä, istunnon tunnus, aikaleimat ja lopetussyy, vaikka rutiinisähköpostit ryhmiteltäisiin, vaimennettaisiin tai lähetettäisiin pienelle päivystyslistalle. Vakavuuskynnys on toimituksen suodatin, ei sen elinkaaritapahtuman valinta, jonka halusit ilmoittaa.
Lähetä vähimmäiskonteksti, jonka vastaanottaja tarvitsee löytääkseen suojatun tietueen. Tilin nimet, sisäiset osoitteet ja istunnon tiedot ovat arkaluontoisia, ja sähköposti, joka välittyy hyvin eteenpäin, on sähköposti, joka vuotaa hyvin.
Todista se sitten päästä päähän. Aja tavallinen kirjautuminen ja uloskirjautuminen, uudelleenyhdistäminen, kaksi samanaikaista istuntoa ja pakotettu toimitusvirhe, ja jäljitä yksi tapahtuma yhdyskäytävästä kerääjän kautta toimitettuun viestiin. Jos sähköposti saapuu ilman istunnon tunnusta, sopimus on puutteellinen. Jos kaksi sähköpostia kuvaa yhtä istuntoa, korrelaatio on rikki. Kumpikaan ongelma ei näy, kun ainoa asia, jota testaat, on että postin toimitus toimii.