TLS სერთიფიკატები და ავტომატური გაფართოება

რატომ გჭირდებათ ეს

TLS დაშიფრავს კლიენტ-სერვისის ტრაფიკს, ადასტურებს სერვერის ნამდვილობას (და mTLS- ით - კლიენტს) და ასევე იცავს ჩანაცვლებას. ძირითადი რისკები: სერთიფიკატების დაგვიანება, სუსტი გასაღებები, არასწორი ნდობის ჯაჭვი, სახელმძღვანელო პროცედურები. სტატიის მიზანია არქიტექტურის აღწერა, რომელშიც სერთიფიკატები ყოველთვის აქტუალურია და მომხმარებლებისთვის როტაცია შეუმჩნეველია.

ძირითადი ცნებები

CA/ხელმოწერა: სასერთიფიკატო ცენტრი (საჯარო ან შიდა).
Fullchain: ფურცლის სერთიფიკატი + შუალედური + ფესვი (ჩვეულებრივ ფესვი კლიენტის საცავებში).
SAN (Subect Alternative Name): დომენების/IP სია ერთი სერთიფიკატისთვის (მრავალ-SAN).
Wildcard: `.example. com '- მოსახერხებელია მრავალი ქვედანაყოფისთვის, მოითხოვს DNS ვალიდაციას.
OCSP stapling: სერვერი იყენებს გაწვევის ახალ სტატუსს; ამცირებს შეფერხებებს და დამოკიდებულებას გარე OCSP- ზე.
HPKP: მოძველებული/არ გამოიყენება; ამის ნაცვლად - CT ლოგები და ძირითადი ჰიგიენა.
CT (Certificate Transparence): გაცემის საზოგადოებრივი ლოგიკა მნიშვნელოვანია ყალბი საკითხების გასაკონტროლებლად.

კრიპტოპროფილი და გასაღებები

ალგორითმები:

ECDSA (P-256) - სწრაფი და კომპაქტური; სასურველია თანამედროვე მომხმარებლებისთვის.
RSA-2048/3072 - კვლავ თავსებადი; შეგიძლიათ შეინახოთ ორმაგი cert (RSA + ECDSA).
გასაღების გამომუშავება: მხოლოდ სამიზნე მხარეს (არ გადაიტანეთ პრივატიზატორები ქსელში), დაიცავით წვდომის უფლებები ('0600').
HSM/KMS: კრიტიკული ზონებისთვის (გადახდის/PII) შეინახეთ გასაღებები HSM/KMS- ში, ჩართეთ ოპერაციების აუდიტი.
ცხოვრების დრო: მოკლე სერთიფიკატები (90 დღე/30 დღე შიდა) ხელს უწყობს ხშირი როტაციას და ამცირებს კომპრომისების რისკს.

TLS არქიტექტურული მართვის მოდელები

1. საზოგადოებრივი CA ACME- ს საშუალებით (Let's Encrypt/Buypass/და ა.შ.)

სავალდებულო: HTTP-01 (ვებ სერვერის/Ingress- ის საშუალებით) ან DNS-01 (wildcard/დაუგეგმავი დომენებისთვის).
დადებითი: უფასო/ავტომატიზირებული, ფართო ნდობა. უარყოფითი მხარეები: გარე დამოკიდებულება.

2. შიდა კორპორატიული CA

ინსტრუმენტები: HashiCorp Vault PKI, Smallstep (ეტაპი), Microsoft AD CS, CFSSL.
დადებითი: კასტომიური პოლიტიკოსები, mTLS, მოკლე TTL, გამოშვება შიდა დომენებისთვის. უარყოფითი მხარეები: ფესვის განაწილება, ნდობის მართვა.

3. ჰიბრიდი

საჯარო CA გარე მომხმარებლებისთვის; შიდა CA - სერვისის მომსახურებისთვის (mTLS), ინტერკლასტური არხები და ადმირალები.

ავტომატური გახანგრძლივების ნიმუშები

ზოგადი პრინციპები

გახანგრძლივების ბარიერი: დაიწყეთ გასვლამდე '30' დღის განმავლობაში; კრიტიკული მომსახურებისთვის - „45 დღის განმავლობაში“.
Zero-downtime: ახალი სერთიფიკატის გამოშვება, ატომური ჩანაცვლება, გლუვი reload კავშირების რღვევის გარეშე.
ორმაგი დაჭერა (ცისფერი/მწვანე): შეინახეთ მიმდინარე და შემდეგი მხარე; გადართვა - symlink ან ვერსიონირებული საიდუმლო.
ალერტინგი: გაფრთხილებები 45/30/14/7/3/1 დღისთვის; ცალკე ალერტი ACME გამოწვევის წარუმატებლობის დროს.

ACME კლიენტები და მათი გამოყენება

certbot / acme. sh/lego: მსუბუქი აგენტები VM/bare-metal.
cert მენეჯერი (Kubernetes): ოპერატორი, რომელიც მუშაობს Issuer/ClusterIssuer- თან; ავტომატიზაციას უწევს release/renew და ჩაწერს საიდუმლოებას.
step-ca/Vault Agent: ავტომატური გამოშვება/როტაცია მოკლე TTL, sidecar ნიმუშები გასაღებების და ჯაჭვების განახლებისთვის.

Kubernetes პროცესები

cert მენეჯერი (Issuer- ის მაგალითი Let's Encrypt- ისთვის, HTTP-01 Ingress- ის საშუალებით):

yaml apiVersion: cert-manager. io/v1 kind: ClusterIssuer metadata:
name: le-http01 spec:
acme:
email: devops@example. com server: https://acme-v02. api. letsencrypt. org/directory privateKeySecretRef:
name: le-account-key solvers:
- http01:
ingress:
class: nginx

სერტიფიკატის მოთხოვნა:

yaml apiVersion: cert-manager. io/v1 kind: Certificate metadata:
name: app-cert namespace: prod spec:
secretName: app-tls dnsNames:
- app. example. com issuerRef:
name: le-http01 kind: ClusterIssuer privateKey:
algorithm: ECDSA size: 256 renewBefore: 720h # 30 дней

ცხელი ჩანაცვლება NGINX-Ingress- ში ხდება ავტომატურად „საიდუმლო“ განახლების დროს. დაამატეთ 'ssl-ecdh-curve: secp256r1' და ჩართეთ OCSP stapling პრეზენტაციების/ConfigMap- ის საშუალებით.

პროცესები VM/Bare-metal

Certbot (HTTP-01):

bash sudo certbot certonly --webroot -w /var/www/html -d example. com -d www.example. com \
--deploy-hook "systemctl reload nginx"

პერიოდული 'certbot renew' სისტემის საშუალებით.
ველური ბარათისთვის გამოიყენეთ DNS-01 (provider-plagin) და მსგავსი '-deploy-hook'.

acme. sh (DNS-01, wildcard):

bash export CF_Token="" # example for Cloudflare acme. sh --issue --dns dns_cf -d example. com -d '.example. com' \
--keylength ec-256 --ecc \
--reloadcmd "systemctl reload nginx"

NGINX: ატომური ჩანაცვლება

შეინახეთ 'fullchain. pem` и `privkey. pem 'სტაბილური მარშრუტების ქვეშ (symlink ვერსიონირებული ფაილებისთვის), შემდეგ' nginx -s reload '.

შიდა PKI და mTLS

HashiCorp Vault PKI (როლის მაგალითი):

bash vault secrets enable pki vault secrets tune -max-lease-ttl=87600h pki vault write pki/root/generate/internal common_name="Corp Root CA" ttl=87600h vault write pki/roles/service \
allowed_domains="svc. cluster. local,internal. example" allow_subdomains=true \
max_ttl="720h" require_cn=false key_type="ec" key_bits=256

ავტო გამოცემა: Vault Agent Injector (K8s) ან sidecar; პროგრამა ხელახლა კითხულობს ფაილს/FS-watcher.
მოკლე TTL: 24-720 საათი, რაც ასტიმულირებს ხშირი როტაციას და ამცირებს მოპარული გასაღების ღირებულებას.
mTLS: გაიცემა კლიენტის სერთიფიკატები კონკრეტული სერვისების/როლებისთვის; შესასვლელში - მუტალური TLS ingress/sidecar-proxy.

უსაფრთხო ოპერაცია

საიდუმლოების გამიჯვნა: პირადი გასაღებები - მხოლოდ მასპინძელ/პოდზე, მინიმალური შეღავათების პრინციპზე წვდომა.
ფაილების უფლებები: '600' გასაღებისთვის; მფლობელი - პროცესის მომხმარებელი.
გრეის პერიოდი: დაამონტაჟეთ 'renewBefore' საკმარისი, რომ გაითვალისწინოთ DNS/ACME/პროვაიდერის გაუმართაობა.
OCSP Stapling: ჩართეთ ფრონტზე; აკონტროლეთ პასუხის სიახლე (ჩვეულებრივ 12-72 საათი).
HSTS: ჩართეთ თანდათანობით (თავიდანვე 'preload' გარეშე), დარწმუნდით ყველა შინაარსის სწორად HTTPS მიწოდებაში.
ორმაგი cert (RSA + ECDSA): აუმჯობესებს თავსებადობას და შესრულებას; მიეცით ECDSA თანამედროვე მომხმარებლებს.

მონიტორინგი და SLO

მეტრიკა და შემოწმება:

თითოეული დომენის/საიდუმლოებისთვის გასვლამდე დღეები; SLO: „არ არსებობს cert <7 დღიდან ექსპერიმენტამდე“.
ჯაჭვის მიზანშეწონილობა (ლინტინგი), SAN- ის შესაბამისობა საჭირო დომენებისთვის/IP.
OCSP სტაპლინგის სტატუსი (პასუხის სიახლე).
წარმატებული/წარუმატებელი ACME გამოწვევების წილი.
Leitensi TLS ხელი, პროტოკოლის/შიფრის ვერსიები (audit).

ალერტა (დონის მაგალითი):

Warn: გასვლამდე 30 დღე.
Crit: 7 დღე/მარცხი 'renew'.
გვერდი: 72 საათი/არასტაბილური ჯაჭვი გაყიდვაში/არ არის OCSP stapling.

ინციდენტები და გამოტოვება

სერთიფიკატის შეფერხება: დროებით ხელახლა გაშვება და ხელით დალაგება, RCA- ს დაფიქსირება (რატომ არ მუშაობდა renew, DNS დაბლოკვა/API შეზღუდვები).
გასაღების კომპრომისი: დაუყოვნებლივი ხელახლა გამოცემა/მიმოხილვა, საიდუმლოებების როტაცია, დაშვების აუდიტი, DNS პროვაიდერის ნიშნების როტაცია/ASME ანგარიში.
არასწორი ჯაჭვი: სწორი „fullchain“ - ის გადაუდებელი გამონაყარი, იძულებითი reload ფრონტები.
Lock-in DNS პროვაიდერის მიმართ: შეინარჩუნეთ სარეზერვო ვალიდაციის გზა (HTTP-01) ან მეორადი DNS.

ავტო წარმოების განხორციელების შემოწმების სია

1. შეარჩიეთ მოდელი (საზოგადოებრივი CA ACME/შიდა PKI/ჰიბრიდების საშუალებით).
2. განსაზღვრეთ კრიპტოპროფილი: ECDSA-P256, საჭიროების შემთხვევაში, ორმაგი წრე RSA-2048.
3. პარამეტრი ავტომატური აგენტი (cert მენეჯერი, certbot, acme). sh, Vault Agent).
4. მოაწყეთ zero-downtime ჩანაცვლება (symlink pattern, hot-reload ingress/NGINX/Envoy).
5. ჩართეთ OCSP სტაპლინგი და HSTS (ეტაპობრივად).
6. დაამატეთ ჩელენჯის ვადების და სტატუსის ალერტინგი; დანიშნეთ SLO.
7. აღწერეთ break-glass და სახელმძღვანელო გამოშვების პროცესები.
8. ჩაატარეთ „სახის“ ვარჯიშები: გატეხილი DNS-01, ACME ვარდნა, ამოიწურა ფესვი/შუალედური.
9. გადახედეთ პირადი კლავიშების ხელმისაწვდომობას, გადაიტანეთ DNS პროვაიდერის ნიშნები და ACME ანგარიშები.

მახასიათებლები iGaming/fintech

PCI DSS/PII: მკაცრი Cipher Suites, იძულებითი TLS 1. 2+/1. 3, გამორთეთ სუსტი შიფრები/შეკუმშვა, უსაფრთხოების კომპრომისების გარეშე.
დომენების სეგმენტი: ცალკეული სერთიფიკატები გადახდის ჩანაწერებისა და ადმირებისთვის; შინაარსის პროვაიდერებისთვის - იზოლირებული ჯაჭვები.
აუდიტი და ლოჯისტიკა: ჩაწერეთ გამომავალი/მიმოხილვა/როტაცია; ხელი მოაწერეთ CI/CD არტეფაქტებს.
მრავალმხრივი: ადგილობრივი Issuer-s რეგიონებში, ისე რომ არ იყოს დამოკიდებული ჯვარედინი რეგიონალური უარი.

კონფიგურაციის მაგალითები

NGINX (RSA+ECDSA, OCSP stapling)

nginx ssl_protocols TLSv1. 2 TLSv1. 3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_ecdh_curve secp256r1;

ssl_certificate   /etc/nginx/certs/app_ecdsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_ecdsa/privkey. pem;
ssl_certificate   /etc/nginx/certs/app_rsa/fullchain. pem;
ssl_certificate_key /etc/nginx/certs/app_rsa/privkey. pem;

ssl_stapling on;
ssl_stapling_verify on;

add_header Strict-Transport-Security "max-age=31536000" always;

OpenSSL: CSR (ECDSA-P256)

bash openssl ecparam -name prime256v1 -genkey -noout -out privkey. pem openssl req -new -key privkey. pem -out csr. pem -subj "/CN=app. example. com" \
-addext "subjectAltName=DNS:app. example. com,DNS:www.example. com"

CFSSL: პროფილი და გაცემა

json
{
"signing": {
"profiles": {
"server": {
"usages": ["digital signature","key encipherment","server auth"],
"expiry": "2160h"
}
}
}
}

bash cfssl gencert -profile=server ca. json csr. json      cfssljson -bare server

FAQ

საჭიროა ველური ბარათი?
თუ ხშირად ჩნდება ახალი ქვედანაყოფები - დიახ (DNS-01 მეშვეობით). წინააღმდეგ შემთხვევაში, გამოიყენეთ SAN მულტფილმები აშკარა დომენებისთვის.

რა უნდა აირჩიოთ: cert მენეჯერი ან certbot?
Kubernetes → cert-manager. VM/მიკრო სერვისები K8s- ის გარეთ არის certbot/lego/acme. sh. შიდა PKI - Vault/step-ca.

შესაძლებელია TTL- ის შემცირება დღეში?
შიდა mTLS- ისთვის - დიახ, თუ ავტომატიზაცია/sidecar გარანტირებულია როტაციით და აპლიკაციებს შეუძლიათ ცხელი რელიეფი.

როგორ დავიცვათ DNS-01?
ცალკეული ნიშანი/მინიმალური წვდომა ზონაში, გასაღების როტაცია, შეზღუდვა IP API წვდომა, აუდიტის ჩატარება.

შედეგი

TLS- ის საიმედო მენეჯმენტი არის სწორი კრიპტოპროფილის, ავტომატიზირებული გამოშვებისა და გახანგრძლივების, zero-downtime როტაციების, დაკვირვებისა და საპასუხო ინციდენტის აშკარა პროცედურების ერთობლიობა. ააშენეთ ACME/PXI კონვეიერი, დაამატეთ მკაცრი ალერტინგი და რეგულარულად მოამზადეთ „გადაუდებელი“ სცენარები - და ამოწურული სერთიფიკატები შეწყვეტს ღამის პეიჯერების წყაროს.