AWS Client VPN: які CA павінен выдаваць кліенцкія сертыфікаты?
Існуючы CA, уласны эмітэнт і AWS Private CA дзеляць працу па-рознаму. Вызначце, хто ўхваляе, абнаўляе і адклікае кліенцкія сертыфікаты, перш чым запускаць.
Пытанне сертыфікатаў у AWS Client VPN задаюць як пытанне прадукту, а насамрэч гэта аперацыйнае пытанне. Любая з трох звычайных схемаў будзе трымаць працоўны тунэль: існуючы арганізацыйны CA, асобны ўласны эмітэнт або AWS Private CA. Яны адрозніваюцца тым, хто ўхваляе прыладу, хто трымае ключ подпісу і хто адказвае, калі ноўтбук знікае ў нязручную гадзіну. Выбярыце варыянт, уладальніка якога вы можаце назваць.
AWS не патрабуе Private CA для аўтэнтыфікацыі па сертыфікатах. Размяшчэнне сервернага сертыфіката ў ACM — гэта крок разгортвання, а не працэс рэгістрацыі.
Тры ўмовы, якія вызначаюць выбар
Тры ўмовы ясна раздзяляюць варыянты: ці ўжо існуе ўхвалены працэс рэгістрацыі прылад, ці можаце вы трымаць ключ подпісу з рэзервовымі копіямі і прызначаным уладальнікам, і як адкліканне дасягае канчатковага пункта. Кожная ўмова блізкая да «так» або «не», і першае «не» звычайна вызначае архітэктуру.
Праходзьце іх па парадку. Скачок адразу да параўнання выдаткаў — гэта шлях да таго, што каманда застанецца з кіраваным CA і ніхто не ведае, хто выдасць наступны сертыфікат для ноўтбука.
| 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 |
Умова першая: ці існуе рэгістрацыя ўжо?
Калі ваша арганізацыя ўжо кіруе CA з ухваленым шляхам рэгістрацыі прылад, выдача кліенцкіх сертыфікатаў Client VPN з яго — найкарацейшы шлях. Ухвалы, працэс і запісы актываў ужо ёсць. Асобны падпарадкаваны эмітэнт у гэтай іерархіі звычайна лепшы за CA агульнага прызначэння, бо дае VPN уласную мяжу даверу і ўласны спіс адклікання. Трымайце гэты спіс асобна ад астатняй іерархіі, каб інцыдэнт VPN не прымушаў да змен ва ўсёй PKI.
Калі такога працэсу няма, сапраўднае пытанне — ці хочаце вы яго пабудаваць. CA лёгка пачаць і дорага дрэнна ўтрымліваць.
Умова другая: ці можаце вы кіраваць ключом подпісу?
Уласны эмітэнт працуе з дакументаванай мадэллю імпарту, і EasyRSA або невялікі ўнутраны інструмент можа стварыць матэрыял. Запуск каманды — не самае цяжкае. Самае цяжкае — афлайн-рэзервовыя копіі ключа подпісу, шлях аднаўлення, які хтосьці сапраўды праверыў, уладальнік, які не ў адпачынку, і правіла, што ключ ніколі не трапляе ў кліенцкі пакет або экспарт канфігурацыі. Запішыце гэта як працэдуру да выхаду першага сертыфіката, а не пасля першага інцыдэнту.
AWS Private CA пераносіць гэтае захоўванне ў кіраваны сэрвіс. Ён не пераносіць палітыку рэгістрацыі, крок ухвалы або дастаўку сертыфіката на прыладу.
Умова трэцяя: як прыходзіць адкліканне?
Client VPN спажывае спіс адклікання кліенцкіх сертыфікатаў, які вы імпартуеце ў канчатковы пункт, як апісана ў кіраўніцтве па жыццёвым цыкле сертыфікатаў. Публікацыя CRL у іншым месцы вашай PKI не праштурхвае яго ў сэрвіс. Імпарт — асобная, запланаваная аперацыя, а пратэрмінаваны спіс спыняе злучэнні, а не дэградуе ціха. Пастаўце абнаўленне на той жа каляндар, што і самі сертыфікаты.
Гэта робіць абнаўленне пунктам маніторынгу з уладальнікам, а не задачай, якую вы закрываеце пры запуску. Адклічце адзін тэставы сертыфікат ад пачатку да канца, перш чым механізм спатрэбіцца ўсур'ёз.
Чаго не выдаляе ні адзін варыянт
Кожны варыянт па-ранейшаму патрабуе аднаго асобнага кліенцкага сертыфіката і ключа на кожную незалежна кіраваную прыладу. Дапаможнік, які выдае адну асобу ўсім, — гэта дапаможнік-скаротка, і ён таксама робіць выбарачнае адкліканне немагчымым.
Імпартаваныя серверныя сертыфікаты ў ACM не маюць кіраванага абнаўлення, таму ўладальнік павінен атрымаць замену, паўторна імпартаваць яе і потым пацвердзіць, што канчатковы пункт яе прыняў. Абнаўленне сервернага сертыфіката не абнаўляе кліенцкія дадзеныя, якія ўжо ляжаць на ноўтбуках. Гэта асобныя жыццёвыя цыклы з асобнымі календарамі.
Праверце тыпы ключоў і пашырэнні, якія прымае сэрвіс, перад тым як нешта выдаваць. Тое, што CA падтрымлівае алгарытм, не значыць, што канчатковы пункт яго прыме.
Перад запускам правядзіце адно абнаўленне і выдаленне аднаго кліента праз абраны працэс і запішыце, якія дадзеныя змяніліся, якая налада канчатковага пункта змянілася і што адбылося з актыўнай сесіяй. Калі гэтае практыкаванне скончыцца без яснага ўладальніка, выбар эмітэнта не завершаны.