TLS сертификаттары үшін ішкі ACME: офлайн ұзарту

Мәселе: сертификаттар мерзімі өтіп, сервис тоқтайды

TLS сертификаттары көбіне соңғы сәтте еске түседі: пайдаланушылар браузердегі ескертуді көргенде, API қателер бере бастағанда немесе VPN клиенттері қосылмай қалғанда. Себебі қарапайым — қолмен ұзарту күнтізбеге, мұқияттыққа және қажетті жүйелерге қолжетімділікке тәуелді. Бір ғана өткізіп алған мерзім, бір қызметкер демалыста, немесе тізбектегі аралық буын ұмытылса — сервис кодтан емес, сенімнің әлсіреуінен істен шығады.

Жабық контурларда бұл проблема өткірірек. «Интернетке шығуы жоқ» әдетте мынады білдіреді:

• уздер қоғамдық CA-ларға және олардың тексерулеріне жүгінбей алады;
• сыртқы DNS жазбаларын жариялай алмайды не жаңарта алмайды;
• сырттан келетін тексерістерді қабылдай алмайды;
• бұлттағыдай тез жаңартулар мен құралдар орната алмайды.

Алайда сертификаттар everywhere керек, және жиі ең көрінетін әрі маңызды нүктелер зардап шегеді: веб-порталдар мен ішкі панельдер, интеграция API-лары, пошта серверлері, VPN-шлюздер, аутентификация сервистері және жабдық басқару панельдері.

Осылайша ондай сервистер ондаған болғанда қолмен амал схемасы лотереяға айналады: бір жерде сертификатты жаңартқанымен балансировщикті қайта іске қосуды ұмытады; бір жерде кластердің тек бір түйінінде жаңартылды; бір жерде қате атауымен сертификат шығарылды. Сондықтан ішкі ACME TLS сертификаттары үшін «процестің әдемілігін» емес, төрт практикалық мақсатын шешеді: жұмыстың үздіксіздігі, шығару үстінен біріккен бақылау, мерзім бойынша алдын ала әрі болжамды ұзарту және аудит (кім, не, қашан және қандай негізбен алған).

ACME қысқаша: рөлдер мен меншік тексеру логикасы

ACME — сертификаттарды автоматты түрде шығару және ұзарту протоколы. Қарапайым тілмен айтсақ, үш рөл бар: клиент (сервердегі агент), ACME-сервер (сұраныстарды қабылдайтын нүкте) және нәтижесінде сертификатты қол қоятын сертификаттау орталығы (CA). Клиент сертификат сұрайды, ACME-сервер тексеру тапсырмасын береді, клиент аталған атауды басқаратынын дәлелдейді, сосын CA сертификатты шығарады.

ACME-дің «сертификатты көшіріп әкелетін скриптен» маңызды айырмашылығы — шығару доменнің меншік тексеруіне және клиент есептік жазбасына байланыстырылған. Сонымен қатар протокол циклдың барлық кезеңін сипаттайды: сұраныс, тексеріс, шығару, ұзарту, қайтару. Бұл сертификаттарды «қате жерге тыныштықпен» шығарудың қаупін төмендетеді және процесті бақылауда ұстауға көмектеседі.

Әдетте қолданылатын меншік тексерулер (challenge):

• HTTP-01: доменде HTTP арқылы токен орналастыру (ортақ веб-қол жетімділік бар болса ыңғайлы).
• DNS-01: DNS-та TXT жазбасын жасау (сегменттелген желілерде ең практикалық нұсқа жиі сол).
• TLS-ALPN-01: 443 портта TLS арқылы токен қайтару (уақытша TLS-жауап орнату оңай болған жағдайда жарайды).

Жабық контурда көбіне DNS-01 жеңіске жетеді: әр қызметке HTTP қолжетімділік ашудың қажеті жоқ, тек басқарылатын ішкі DNS жеткілікті.

Кілт қайда сақталатыны саясатқа байланысты. Көп жағдайда кілт қосымша серверінде жасалып, сол жерде ротатцияланады. Қатты талаптар болғанда кілт HSM-да немесе құпияларды сақтау жүйесінде жасалып, сақталуы мүмкін — бұл кілттің ағуын азайтып, админдердің қолын шектейді.

Архитектура: ішкі ACME контурында не болады

Ішкі ACME әдетте желінің ішінде шағын контур ретінде құрылады: жеке сервис сертификаттарды шығарады және ұзартуларды орындайды, ал қосымшалар тек сұрайды да, оларды өз endpoint-теріне қояды. Осылай қолмен шығаруды алып тастап, бақылауды сақтайсыз.

Негізгі компоненттер жиыны былай көрінеді:

• Ішкі желідегі ACME-сервер: шығару сұраныстарын қабылдайды, меншік тексеруді ұйымдастырады және дайын сертификатты береді.
• Жеке сертификаттау орталығы (CA): root сертификаты барынша оқшауланған жерде сақталады, ал шығару көбінесе аралық (intermediate) CA арқылы жүреді.
• DNS және DHCP: атаулар мен IP тәртібін ұстап тұрады; DNS көбінесе доменді растама үшін қолданылады.
• Құпиялар хранилищесі: ACME аккаунт кілттерін, автоматтандыру токендерін және қажет болса DNS-ке қолжеткізу кілттерін қауіпсіз сақтау орны.
• Интеграциялық нүктелер: сертификат реалды қажеттілігі бар жерде қолданылатын орындар.

CA-ны root және intermediate-ке бөлу маңызды: егер intermediate кілті ағып кетсе, сіз тек оны қайтарып, қайта шығарсаңыз болғаны, бүкіл ұйымның сенімін қайта құрудың қажеті жоқ. Root әдетте офлайн немесе қатты шектелген сегментте болғаны дұрыс.

DNS пен DHCP сенім тізбегінің бір бөлігіне айналады: егер біреу жазбаларды еркін жасай алса, ол тексеруден өтіп, сертификат алуға мүмкіндік алады. Сондықтан аймақтар мен жазбаларды жаңарту құқықтары, өзгерістер журналы анық және шектелген болуы керек.

Интеграциялар стандартты ACME клиенттері арқылы және конфигурацияны автоматты қайта жүктеу арқылы жасалады; мысалы:

• веб-серверлер мен API-лар
• балансировщиктер
• Kubernetes ingress
• reverse proxy
• пошта мен ішкі порталдар

Жабық контурларда (мемлекеттік мекемелер немесе банктердің деректер орталықтарында) бұл тәсіл сертификат мерзімдерін қысқа ұстап, интернетке тәуелсіз жұмыс істеуге мүмкіндік береді.

Сенім мен бақылау: ішкі CA-ны «баспа машинасына» айналдырмау

Ішкі ACME қолмен жұмысты азайтады, бірақ жаңа тәуекелдерді әкеледі: егер шығару ережелері әлсіз болса, кез келген сервис сыртқы атауға сертификат ала алады. Сондықтан басты назар жылдамдық емес — сенім мен бақылауда болуы керек.

Бастапқы қағида: root CA барынша қол жетпес болу керек. Оны офлайн сақтап, тек intermediate шығару немесе ротатция үшін қосады; оған кіру тек реттелген әкімшілер тобына беріледі. Құлыпталған сейф, желіден ажыратылған бөлек машина, іс-әрекеттер журналы және маңызды операцияларға екі адамдық бекіту күрделі сұлбалардан гөрі қауіпсіздікті қамтамасыз етеді.

Аралық (intermediate) CA — негізгі жұмысшы атқаратын. Ол сертификаттарға қол қояды, қысқа өмір сүріп (мысалы, 1–3 жыл), және инцидент болғанда оңай қайтарылады. Ротацияны алдын ала ойластыру маңызды: жаңа intermediate алдын ала шығарылады, клиенттерде сенім жаңартылады, содан кейін ескі шығарылады.

Ішкі root-қа сенімді басқарылатын түрде таратыңыз: жұмыс станцияларына және серверлерге домен саясаттары арқылы, мобильді құрылғыларға MDM арқылы, жұқа клиенттерге базалық образ немесе орталық конфигурация арқылы. Медицина және өндірістегі құрылғыларды бөлек тексеріңіз — оларда жаңартулар сирек болуы мүмкін.

Жүйені ұстайтын саясаттар

Жақсы шығару саясаты әдетте бес сұраққа жауап береді:

• Кімде шығару сұрауға құқығы бар (топтар, сервис аккаунттар, желі сегменттері).
• Қандай атаулар рұқсат етілген: тек ішкі DNS зонасы тізімі, сыртқы домендерге тыйым.
• Wildcard рұқсат етіле ме және қандай (оларды шектеу керек).
• Қандай SAN-дар қабылданады (мысалы, тек белгілі жоба немесе бөлім ішінде).
• Ең ұзақ мерзімдер және қайта шығару жиілігі, «мәңгі» сертификаттардың көп болмауы үшін.

Аудит: қандай іздер сақталуы керек

Логтар кім сұрағанын, меншік қалай дәлелденгенін, нақты не шығарылғанын (CN/SAN, мерзім, отпечаток) және егер қолмен бекіту болса — кім бекіткенін көрсетуі тиіс. Жабық желіде (мемлекеттік тапсырыс беруші немесе банк жағдайында) бұл «неліктен осы сервис сертификат алды» деген сауалға жылдам жауап беруге және қате өтініштерді уақытында тоқтатуға көмектеседі.

Ішкі доменді қалай растау: DNS, HTTP және сегментация ерекшеліктері

Ішкі ACME-дің негізгі мәселенің бірі — қызмет желі оқшауланған кезде доменге шын мәнінде кім иелік ететінін қалай дәлелдеу. Жабық контурда көбіне DNS-01 жеңіске жетеді, себебі ол әр қызметке HTTP қолжетімділікті қажет етпейді және сегменттер арасында жақсы жұмыс істейді.

DNS-01 негізінен стандартты нұсқа: ACME-клиент уақытша TXT жазбасын ішкі DNS зонасына қояды, ACME-сервер корпоративтік DNS арқылы оны тексереді. Бұл көп сервистер, балансировщиктер, NAT және жабық порттар болғанда ыңғайлы.

HTTP-01 да мүмкін, бірақ ол күрделіірек. ACME-сервер нақты хост пен тексеру жолына HTTP арқылы жетуі керек, маршрутизация мен прокси сұрауды өзгертпеуі тиіс. Егер сервис көп, адрес тұрақсыз немесе барлығы бір reverse proxy артында болса, немесе ACME зонаның DMZ-ге жетілуі шектелсе, ол қолайсыз болады.

Таңдау мысалы:

• DNS-01: жабық желілер үшін, DMZ және wildcard үшін ең жақсы таңдау
• HTTP-01: нақты және тұрақты бағыт бар жеке сервистер үшін оңай
• Wildcard: микросервистерге ыңғайлы, бірақ шығаруға қатты бақылау керек

Wildcard сертификаттары (*.corp.local) шығарулар санын азайтады, бірақ бақылауды әлсіретеді: бір кілт бірден көп атауларға жол ашады. Сондықтан олар әдетте тек платформалық командаларға және белгілі зонаға ғана беріледі.

Сегментация маңызды: DMZ және ішкі зоналар үшін бөлек саясат қойыңыз (кім сұрай алады, қандай домендерге, қандай мерзіммен). Жақсы тәжірибе — әртүрлі қауіп деңгейі бар желілер үшін бөлек ACME аккаунттары мен шығару профильдері.

Ұзарту дауылын болдырмау үшін шектеулер енгізіңіз:

• доменге және командаға шаққандағы шығарудың жиілігін шектеу
• ұзарту кестесіне джиттер (кездейсоқ ығысу) қосу
• DNS апатында жаппай шығаруды блоктау
• сезімтал зоналарда wildcard үшін міндетті қосымша растау

Мысалы, жабық ауруханалық желіде DMZ-дегі сервистер атауларын DNS-01 арқылы растайды, ал ішкі әкімшілік панельдерге бөлек зона және қатты шектеулер беріледі — бір автоматтандыру қатесі бүкіл инфрақұрылымды тоқтатпау үшін.

Интернетсіз орналастыру нұсқалары: толық офлайн және жартылай офлайн

Ішкі ACME үшін әдетте екі режим таңдалады: толық офлайн, яғни бүкіл контур жабық желінің ішінде өмір сүреді, немесе жартылай офлайн, яғни саясаттар мен жаңартулар үшін қатаң бақылаудағы «көпір» бар.

Толық офлайн

Осы схемада периметр ішінде орналасқан: жеке CA (root және әдетте бөлек intermediate), ACME-сервер, ACME дерекқоры, DNS (егер DNS-01 қолдансаңыз) және клиенттер (мысалы, Certbot немесе прокси ішіндегі ACME-клиенттері). Сыртқы тексерулер жоқ, қоғамдық DNS пен сыртқы репозиторларға жүгіну жоқ.

Артықшылығы — болжамдылық пен қауіпсіздік. Кемшілігі — жаңартулар мен түзетулерді өз қолыңызбен жоспарлап, әкеліп орнатуыңыз керек.

Жартылай офлайн «көпірімен"

Бұл жағдайда сертификат шығару контурлары оқшауланған күйінде қалады, бірақ белгілі бір түйін немесе процесс бар, ол кестеге сай ішке келтіреді: ОС және пакет жаңартуларын, жаңа ACME нұсқаларын, отыру тізімдерін, конфигурация шаблондарын және саясат өзгерістерін. Бұл «көпір» ішке біржақты деректер жеткізуге арналған болуы тиіс — сыртқа ештеңе жарияламайды.

Жаңартуларды алдымен стендте сынап, терезелер арқылы өткізу дұрыс. Бір уақытта CA, ACME және клиенттерді өзгертіп алмаңыз — бұлай істесеңіз ақауды табу қиын болады.

Резервтік қалпына келтіруде не тез қалпына келетінін және не қайта шығарылатынын алдын ала анықтаңыз:

• CA және ACME конфигурациялары, саясаттар, сертификат профильдері
• ACME дерекқоры (аккаунттар, тапсырыстар, статустар)
• аудит журналдары және шығару/қайтару оқиғалары
• DNS және HTTP-челлендж конфигурациялары (егер солар сізге тиесілі болса)
• кілт хранилищелері — тек қорғалған түрде (HSM, шифрланған бэкаптар)

Қалпына келтіру жоспары кемінде үш сценарийді қамтуы тиіс: intermediate кілтінің ағуы, ACME түйінінің компрометациясы, қате жаппай шығару. Әр жағдайда кім қайталайды, CRL/OCSP ішкі деңгейде қалай таралады және критикалық сервистерге қалай мәжбүрлі қайта шығару ұйымдастырылатыны алдын ала анықталған болуы қажет (мысалы, ірі кәсіпорынның жабық желісінде немесе GSE.kz сияқты интеграторға берілген ЦОД-тың SLA-сы бар жерде).

Қадам-қадам: ішкі ACME енгізу және автопродлениені қосу

Бастамас бұрын қай атауларды шығаратыныңыз және сертификат қанша уақыт өмір сүретіні туралы шешіңіз. Домент зонасын бекітіңіз (мысалы, *.corp.local, *.svc.intra), маңызды сервистер тізімін және ережелерді — мерзімдер, ұзартуға қалған минималды күндер, кілт талаптары (RSA немесе ECDSA), кілттерді қайда сақтау керектігін анықтаңыз.

Содан кейін сенім тізбегін құрыңыз. Root CA жасаңыз (офлайн ұстау ұсынылады) және күнделікті шығару үшін intermediate CA-ны орнатыңыз. Саясаттарда қай атаулар рұқсат етілетіні, міндетті өрістер, кім сұрай алатыны және компрометацияда қалай қайтару жүргізілетіні көрсетілуі керек.

CA дайын болғаннан кейін ішкі ACME-ді орналастырыңыз: локальды ACME-сервер, ол клиенттерден сұраныстарды қабылдап, меншік тексеріп, intermediate CA арқылы сертификат береді. Журналдандыру мен аудитты бөлек ойластырыңыз: кім сұрады, қандай атау үшін және қай хосттан.

Практикалық енгізу жоспары әдетте мынадай болады:

• Домент зоналарын, атау стандарттарын және мерзім талаптарын сипаттау.
• Root және intermediate CA орнатып, шығару саясаттарын бекіту.
• ACME-серверді орналастырып, оны intermediate CA-ға қосу.
• DNS-01 үшін DNS автоматизациясын орнату: кім жазбаларды өзгертеді және қандай учетпен.
• ACME-клиенттерді қосымшалар серверлеріне орнатып, жаңартудан кейін сервистерді қауіпсіз қайта жүктеуін баптау.

Тесті аяқтау: бір жария емес сервис үшін сертификат шығарып, клиенттерде сенім тізбегін тексеріңіз; содан кейін жоспарлы ұзартуды күтіп (немесе сынақ мақсатында мерзімді қысқартып) жаңарту үздіксіздігін тексеріңіз. Барлығы дұрыс болса, қалған сервистерге топтар бойынша автопродлениені енгізіңіз, алдымен кем маңыздыдан бастап.

Мерзімдерді бақылау: мониторинг, хабарландырулар және есептілік

Автоматты ұзарту бақылауды алып тастамайды. Ішкі ACME қолмен жұмысты жеңілдетсе де, жаңа міндет пайда болады: тізбек ақауын (ACME сервері, challenge, шығару, жеткізу, сервис қайта жүктеу) сертификат мерзімі өтерден бұрын тез байқап қалу.

Не өлшеу керек және бір бақылау панелінде ұстаған жөн:

• Әр атаудың аяқталуына қалған күндер (әсіресе критикалық сервистер бойынша)
• Соңғы 24 сағаттағы және 7 күндегі сәтті ұзартулар пайыздық көрсеткіші
• Сәтсіздіктің жиі себептері: DNS/HTTP challenge, ACME-ге қолжетімсіздік, құқық қатесі
• Сертификаттардың жасы және кестеге сай ұзартылмағандар үлесі
• Сұраныстан түйінде сертификат орнатылғанға дейінгі уақыт

Тексеруді екі деңгейде жүргізген дұрыс. Орталықтандырылған түрде — барлық сегменттер бойынша жалпы көрініс үшін. Және түйінде — сертификат шығарылғанымен қолданылмай қалған жағдайларды («файл жаңартылмаған», «сервис қайта жүктелмеген», «жол қате көрсетілген») табу үшін.

Ескертулер қарапайым праговтармен болсын: 30/14/7/1 күн қалғанда. 30 күнде сервис иесіне хабарласу жеткілікті; 7 және 1 күнде — кезекші топ пен DNS/прокси үшін, келісімдерді күтпестен әрекет ету үшін.

Талдаулар үшін журналдар керек: сертификат шығару және қайтару оқиғалары, challenge әрекеттері, DNS жазбаларының өзгерістері, веб-серверлер мен балансировщиктердің қайта іске қосылулары. Айына бір рет аудит жасаңыз: қолданыстағы сертификаттардың тізімі, қай жерде орнатылғаны, кімнің иелігінде екені және қажеті жоқ атаулар. Бұл ішкі CA-ның «бәріне» сертификат таратуға айналу қаупін төмендетеді.

Қателіктер мен тосқауылдар

Ішкі ACME-ді «интернет секілді» енгізіп алып, кейін одан да қауіпті жағдайға тап болатындар көп. Төменде кең таралған қателіктер және олар қауіпсіздік пен тұрақтылыққа қалай әсер етеді көрсетілген.

Басқаруды бұзатын қателіктер

Ең көп кездесетін қателік — өте ұзақ өмір сүретін сертификаттарды шығару «бәрібір ұзағырақ болса жақсы» деп ойлау. Бұл уақытша тоқтауларды азайтады деп көрінгенімен шын мәнінде бақылауды әлсіретеді: кілт компрометталса мәселе жылдар бойы созылады, апталар емес.

Тағы бір қате — барлық сервистерге бір wildcard беру. Ыңғайлы болғанымен жеке кілттің ағуы бүкіл контурды қатерге ұшыратады және зиянды шектеу мүмкін болмай қалады.

Тәуекелдер сенімді таратудан басталады: root CA-ны «кім керекке» кең тарату — мобильді ноутбуктарға, оқшауланған жұмыс орындарына және уақытша мердігерлерге — нәтижесінде бір жерде сенім орнатылмай қалады (сервис бұзылады), ал бір жерде тым еркін таратылған (подмена қаупі ұлғаяды).

Сақтау және эксплуатация қатесі

Техникалық жағынан ACME-сервер дұрыс жұмыс істесе де, айналасындағы процестер сәл қақпар болуы мүмкін:

• жеке кілттер ортақ папкаларға, құрастыру артефактілеріне немесе CI журналдарына түсіп қалуы мүмкін
• компрометация жағдайында қайтару және тез алмастыру жоспары жоқ
• автопродлениені қосқанымен сервис сертификатты қайта оқымай қалуы мүмкін (reload немесе restart қажет)

Мысалы: сертификат түнде жаңартылды, бірақ таңертең кейбір клиенттер ескірген тізбекті көрді, себебі прокси файлдарды қайта оқымай қалған. Сондықтан автопродлениені әрқашан қайта жүктеу тестімен және «сервис не береді» тексерісімен толықтырыңыз.

Операцияға қосар алдында қысқа чек-лист

Автоұзартуды продқа қосар алдында тек ACME-серверді емес, ұйымдастырушылық тұрғыдан да тексеріңіз. Қателіктер көбіне криптографияда емес, сертификаттардың қайда тұратынын және кім жауапты екенін білмеуден шығады.

Апта үнемдейтін 5 тексеріс

• Барлық TLS нүктелерінің инвентаризациясын жинаңыз: веб пен API, reverse proxy, ingress, хабар алмасу брокерлері, мәліметтер базалары, пошта, ішкі панельдер. Ұмытылған бір нәрсе бірінші бұзылады.
• Домент иелерін және шығару ережелерін анықтаңыз: қандай атауларға рұқсат, кімге wildcard берілуі мүмкін, қандай командалар немесе сервис-аккаунттар сертификат шығаруға құқылы.
• CA рөлдерін бөліңіз: Root CA-ны оқшаулаңыз (сирек қолданыңыз), intermediate-ті ротацияланатын және қысқа өмірлі жасаңыз; кілттер қорғалғанына және алмастыру тәртібі барына көз жеткізіңіз.
• Бір негізгі challenge таңдаңыз және оны автоматизмге дейін жаттықтырыңыз. Жабық желілерде әдетте DNS challenge жеңеді, бірақ зона өзгерту құқықтары, жаңарту кешігулері және ACME-DNS-клиент-арнайы сегментацияны алдын ала тексеріңіз.
• Мерзімдерді бақылауды орнатыңыз: метрикалар, ескертулер, есептер және төтенше ұзарту тесті (мысалы, сынақ сертификаты мерзімін қысқартып, толық ұзарту тізбегін тексеріңіз).

Құжаттар және апаттық әрекеттер

Қайтару және шұғыл алмастыру процесін бекітіңіз: шешімді кім қабылдайды, сенім қорлары қалай тез жаңартылады және жаңа сертификат клиенттермен қабылданбаса қалай оралу керектігі. Бұл кезекші құрам үшін анық және түсінікті болуы тиіс, тек енгізушінің басында ғана емес.

Мысал сценарий: жабық желі және ондаған ішкі сервис

Банк немесе аурухана мысалы: қосымшалар серверлерінде интернетке шығуға тыйым, тек ішкі сегменттер арқылы қатынау бар және тоқтауларға жол жоқ. Онда оншақты сервис: регистратура, жеке кабинеттер, электрондық құжат айналымы, интеграция API-лары, басқару панельдері жұмыс істейді.

Атау көбіне ішкі DNS-та тұрады. Көбіне серверлік және қолданбалы атаулар араласуына жол бермеу үшін бөлек зона болады: мысалы, apps.corp веб сервистерге және infra.corp инфрақұрылымға. Бұл кіру құқықтары мен кім жазбаларды өзгерте алатынын басқаруды жеңілдетеді.

Сосын ішкі ACME іске қосылады. Контурда жеке CA және локальды ACME-сервер орнатылады, әр сервиске ACME-клиент қойылады. Домент меншік растау үшін DNS-01 таңдалады: клиент ішкі DNS-қа уақытша TXT жазбасын қояды, ACME-сервер оны тексеріп, сертификатты шығарады.

Әдеттегі процесс былай жүреді:

• ACME-клиент мерзімді түрде (мысалы, тәулігіне бір рет) сертификат мерзімін тексеріп, алдын ала ұзарту іске қосады.
• Жаңарту сәтті болса, жаңа сертификат қажетті каталогқа қойылады.
• Сервис жұмсақ қайта жүктеледі, осылайша кілттерді тоқтатпай алмастырады.

Мерзім бақылауы мониторинг дашбордында орталықтандырылған түрде жүргізіледі: 30, 14 және 7 күнге дейін қанша сертификат бары көрінеді. Ескерту кезекшілерге жіберіледі, ай сайын ИБ және жүйе иелеріне қысқа есеп дайындалады.

Команда үшін айырмашылық айқын: мерзімді сертификат апаттары азаяды, қолмен өтініштер азаяды, тұрақтылық пен болжамдылық артады. Осындай контурда CA мен ACME-сервер әдетте ЦОД-тағы арнайы локальды серверлерге орналастырылады (мысалы, ЦОД-тың стойкасында), осылайша жүйе сыртқы арналарға тәуелді болмайды.

Келесі қадамдар: пилот, масштабтау және қолдау

Бастау ACME орнатудан емес — есепке алудан өтсін. Қолданыстағы TLS қолданатын сервистер тізімін және жақын уақытта HTTPS қосатындарды жинаңыз. Ерте кезеңде иелерді анықтаңыз: кім домені үшін жауап береді, кім DNS-ке жауапты, балансировщиктер үшін кім жауапты және кім ескертулерді қабылдайды.

Содан кейін мақсатты моделді таңдаңыз: толық офлайн (барлық тізбек ішінде) немесе жартылай офлайн (саясаттар мен жаңартулар үшін бақылаулы шлюз). Бұл шешім миграция жоспарына әсер етеді: root кілтті қайда сақтау, жұмыс станцияларында сенімді қалай жаңарту, ескі қосымшаларға сертификат қалай шығару.

Пилотқа дейін инфрақұрылымның күнделікті қызметке дайын екеніне көз жеткізіңіз:

• Рөлдерді бөлу: CA, ACME және мониторинг бір жерде жиналмауы тиіс
• Резервтік сақтау: кілттер, конфигурациялар, журналдар, шығарылған сертификаттар дерекқоры
• Бақылау: шығару метрикалары, тексеру қателері, сұраныстар санының өсуі
• Қол жеткізу бақылау: сервис аккаунттарға ең аз құқық, іс-әрекеттер аудиті
• Төтенше жоспар: кілт компрометациясы немесе ACME істен шықса не істеу

Пилотты әртүрлі типтегі 2–3 сервисте өткізіңіз: балансировщиктің артындағы веб-сервис, ішкі API және бөлек сегменттегі сервис. Осылай DNS, маршрутизация және саясаттардағы проблемалар жылдамырақ шығады. Тест барысында шығаруға, ұзартуға және сертификатты таратуға кеткен уақытты, және процесте кім қатысқанын тіркеңіз.

Масштабтауды домен зонасы немесе команда бойынша толқындармен жасаған дұрыс. Әр толқынға саясат шаблондары (мерзімдер, SAN, рұқсат етілген кілттер, атау ережелері) және қабылдау критерийлері дайын болсын: автопродление жұмыс істейді, мониторинг мерзімдерді көрсетеді және инциденттер журналдар арқылы талданады.

Егер жобаға сыртқы көмек керек болса, жүйелік интеграторды тарту орынды. Мысалы, GSE.kz сіздің контурға қажетті схема жинауға, CA мен ACME үшін сервер платформасын таңдап орнатуға, мониторингті ұйымдастыруға және 24/7 қолдауды айқын жауапкершілік аймағымен қамтамасыз етуге көмектеседі.