AWS Client VPN: minkä CA:n pitäisi myöntää asiakasvarmenteet?
Olemassa oleva CA, itse ylläpidetty myöntäjä ja AWS Private CA jakavat työn eri tavoin. Päättäkää, kuka hyväksyy, uusii ja peruuttaa asiakasvarmenteet ennen käyttöönottoa.
AWS Client VPN:n varmennekysymys esitetään tuotekysymyksenä, mutta se on todella operatiivinen kysymys. Mikä tahansa kolmesta tavallisesta kokoonpanosta pitää toimivan tunnelin käynnissä: olemassa oleva organisaation CA, erillinen itse ylläpidetty myöntäjä tai AWS Private CA. Ne eroavat siinä, kuka hyväksyy laitteen, kuka pitää allekirjoitusavainta ja kuka vastaa, kun kannettava tietokone katoaa hankalaan aikaan. Valitse vaihtoehto, jonka omistajan pystyt nimeämään.
AWS ei vaadi Private CA:ta varmenneperusteiseen todennukseen. Palvelinvarmenteen sijoittaminen ACM:ään on käyttöönoton vaihe, ei rekisteröintiprosessi.
Kolme ehtoa, jotka ratkaisevat asian
Kolme ehtoa erottaa vaihtoehdot selvästi: onko hyväksytty laitereksiteröintiprosessi jo olemassa, pystytkö ylläpitämään allekirjoitusavainta varmuuskopioineen ja nimetyin omistajin, ja miten peruutus saapuu päätepisteeseen. Jokainen on lähellä kyllä tai ei -vastausta, ja ensimmäinen ei ratkaisee yleensä arkkitehtuurin.
Käy ne läpi järjestyksessä. Hyppy suoraan kustannusvertailuun johtaa siihen, että tiimille jää hallinnoitu CA eikä kukaan tiedä, kuka myöntää seuraavan kannettavan varmenteen.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
Ehto yksi: onko rekisteröinti jo olemassa?
Jos organisaatiosi jo ylläpitää CA:ta, jolla on hyväksytty laitereksiteröintipolku, Client VPN:n asiakasvarmenteiden myöntäminen siitä on lyhin reitti. Hyväksynnät, prosessi ja laitekirjanpito ovat jo siellä. Erillinen alisteinen myöntäjä tässä hierarkiassa on yleensä parempi kuin yleiskäyttöinen myöntävä CA, koska se antaa VPN:lle oman luottamusrajan ja oman peruutusluettelon. Pidä luettelo erillään muusta hierarkiasta, jotta VPN-tapaus ei pakota muutosta koko PKI:hin.
Jos tällaista prosessia ei ole, todellinen kysymys on, haluatteko rakentaa sellaisen. CA on helppo aloittaa ja kallista omistaa huonosti.
Ehto kaksi: pystytkö ylläpitämään allekirjoitusavainta?
Itse ylläpidetty myöntäjä toimii dokumentoidulla tuontimallilla, ja EasyRSA tai pieni sisäinen työkalu voi tuottaa materiaalin. Komennon suorittaminen ei ole vaikea osa. Vaikea osa on allekirjoitusavaimen offline-varmuuskopiot, palautuspolku, jota joku on oikeasti testannut, omistaja, joka ei ole lomalla, ja sääntö, ettei avain päädy koskaan asiakaspakettiin tai kokoonpanon vientiin. Kirjoita se menettelyksi ennen ensimmäisen varmenteen myöntämistä, ei ensimmäisen tapauksen jälkeen.
AWS Private CA siirtää tämän säilytyksen hallinnoituun palveluun. Se ei siirrä rekisteröintikäytäntöä, hyväksyntävaihetta tai varmenteen toimittamista laitteelle.
Ehto kolme: miten peruutus saapuu?
Client VPN käyttää asiakasvarmenteiden peruutusluetteloa, jonka tuot päätepisteeseen, kuten varmenteen elinkaarioppaassa kuvataan. CRL:n julkaiseminen muualla PKI:ssä ei työnnä sitä palveluun. Tuonti on erillinen, aikataulutettu toimenpide, ja vanhentunut luettelo pysäyttää yhteydet sen sijaan, että se heikkenisi hiljaa. Laita uusinta samaan kalenteriin kuin varmenteet itse.
Tämä tekee uusinnasta omistajan omaavan seurantakohteen, ei käyttöönotossa valmistuvaa tehtävää. Peruuta yksi testivarmenne alusta loppuun ennen kuin tarvitset mekanismia oikeasti.
Mitä mikään vaihtoehto ei poista
Jokainen vaihtoehto tarvitsee edelleen yhden erillisen asiakasvarmenteen ja avaimen jokaista itsenäisesti hallinnoitua laitetta kohti. Opas, joka jakaa yhden identiteetin kaikille, on oppaan oikotie, ja se tekee myös valikoivan peruutuksen mahdottomaksi.
ACM:ään tuoduilla palvelinvarmenteilla ei ole hallinnoitua uusintaa, joten omistajan on hankittava korvaava, tuotava se uudelleen ja vahvistettava sitten, että päätepiste otti sen käyttöön. Palvelinvarmenteen uusiminen ei uusi asiakastunnuksia, jotka ovat jo kannettavissa. Ne ovat erillisiä elinkaaria erillisine kalentereineen.
Tarkista avaintyypit ja laajennukset, jotka palvelu hyväksyy, ennen kuin myönnät mitään. Se, että CA tukee algoritmia, ei tarkoita, että päätepiste hyväksyy sen.
Käy ennen käyttöönottoa läpi yksi uusinta ja yksi asiakkaan poisto valitsemassasi työnkulussa ja kirjoita muistiin, mikä tunnus muuttui, mikä päätepisteen asetus muuttui ja mitä aktiiviselle istunnolle tapahtui. Jos harjoitus päättyy ilman selvää omistajaa, myöntäjän valinta ei ole valmis.