Құпияларды басқару: кодтағы құпиясөздер неге қауіпті

Құпиялар (secrets) — деректер қорларының құпиясөздері, API-кілттер, токендер, жеке кілттер мен сертификаттар. Олар кодта, конфигурация файлдарында немесе CI айнымалыларында жатса, репозиторийдің кез келген ағуы инфрақұрылымға қолжетімділіктің ағуына айналады. Дұрыс тәсіл — бірыңғай қойма, идентификация бойынша қолжетімділік, ең аз привилегиялар, қысқа мерзімді тіркелгі деректері және аудит.

Құпиялар әдетте қайда «тұрады»

• Тікелей бастапқы кодта және git тарихында — жойылған құпия да коммиттер тарихында қалады
• Конфигурация файлдары мен docker-образдарда (OWASP Dockerfile-дың ENV және ARG нұсқауларындағы құпиялардан бөлек ескертеді)
• Тым кең топқа қолжетімді CI/CD айнымалыларында
• Мессенджерлерде, wiki-де және кестелерде

Бұл құбылысты secret sprawl — «құпиялардың таралып кетуі» деп атайды. Көшірме көп болған сайын кімнің қолжетімділігі бар екенін түсіну қиындап, ротация қымбаттай түседі.

Іс жүзінде неге қауіпті

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

Құпияларды дұрыс басқару принциптері

Бұл принциптер OWASP Secrets Management Cheat Sheet ұсынымдарымен сәйкес келеді:

1. Орталықтандыру. Ондаған орынның орнына бір қорғалған шешім, сонда командалар әр құпия не үшін қажет екенін және қайда сақталатынын біледі.
2. Идентификация бойынша қолжетімділік және ең аз привилегиялар. Қолжетімділік бүкіл қоймаға емес, нақты құпияларға беріледі; CI-дің сервистік тіркелгілері тек тапсырмаларға қажеттіні алады.
3. Қысқа мерзімді тіркелгі деректері. Мәңгілік құпиясөздің орнына шектеулі мерзімге берілген және пайдаланғаннан кейін кері қайтарылатын уақытша құпиясөз.
4. Автоматты ротация. Құпияларды үнемі ауыстырып тұру ұрланған деректердің өмір сүру мерзімін шектейді.
5. Аудит. Журнал құпияны кім және қашан сұратқанын, бұл мақұлданғанын және сәтсіз әрекеттер қандай болғанын тіркейді.

HashiCorp Vault мұны қалай шешеді

HashiCorp Vault — құпияларды басқарудың ең кең тараған шешімдерінің бірі:

• Secrets: құпияларды орталықтандырылып сақтау және API арқылы бағдарламалық түрде беру.
• Динамикалық құпиялар: Vault әр динамикалық құпияға өмір сүру мерзімі (TTL) бар lease байлайды; мерзім біткенде немесе кері қайтарылғанда құпия әрекет етуін тоқтатады. Мысалы, деректер қорларының құпиялар қозғалтқышы рөл бойынша пайдаланушы жасайды және lease аяқталғанда оны кері қайтарады (құжаттама бойынша — әдепкіде 1 сағат, ең көбі 24 сағат).
• Ротациясы бар статикалық рөлдер: бар тіркелгілер үшін Vault құпиясөзді сақтап, оны кесте бойынша ауыстыра алады.
• Certificates: сертификаттарды сұраныс бойынша шығару, ротациялау және кері қайтару.
• Encryption as a service: кілттерді қосымшада сақтамай деректерді шифрлау.
• Kubernetes, CI/CD, бұлттармен және LDAP/AD-пен интеграциялар.

Динамикалық құпиялардың тергеу үшін айқын артықшылығы бар: сервистің әр данасы өз тіркелгі деректерін алады, ал деректер қорына күдікті сұрауды нақты данаға дейін қадағалауға болады. Vault пен баламалардың арасынан таңдасаңыз, HashiCorp Vault, CyberArk Conjur және бұлттық KMS салыстыруын оқыңыз.

Неден бастау керек

1. Репозиторийлерді құпиялардың бар-жоғына сканерлеңіз (DerScanner сияқты SAST-құралдар кодқа тікелей жазылған құпиясөздер мен кілттерді табады). OWASP құпияларды іздеудің бірнеше құралын қолдануды және олардың нәтижелерін салыстыруды, ал тексерулерді әзірлеуші деңгейінде (pre-commit, IDE) және CI-де іске қосуды ұсынады.
2. Табылған құпияларды ротациялаңыз — оларды бұзылған деп санаңыз.
3. Қойманы орналастырып, алдымен ең маңызды жүйелерді соған көшіріңіз.
4. CI/CD-ге кодтағы жаңа құпияларға тыйым салатын тексеру қосыңыз. Техникалық мәліметтер — GitLab CI-дегі SAST және SCA мақаласында.
5. Қолжетімділікті журналдауды және күдікті сұраулар туралы ескертулерді баптаңыз.

Құпияларды басқару — қауіпсіз әзірлеуді енгізудің жалпы жоспарының қадамдарының бірі; қалған қадамдар DevSecOps: неден бастау керек материалында сипатталған.

CI/CD және контейнерлердегі құпиялар

Жинау конвейерлері — ең осал орындардың бірі. CI сервистік тіркелгілерінің құқықтары жиі кең болады, ал орта айнымалыларын тапсырма конфигурациясын өзгерте алатындардың бәрі көреді. CI/CD үшін OWASP ұсынымдары: сервистік аккаунттардың құқықтарын тек қажетті құпиялармен шектеу, құпияларды алу туралы хабарлау және құпиялардың репозиторий форктарына мұраға қалуына жол бермеу. CI/CD журналдары да, егер құрал айнымалыларды басып шығарса, құпияларды ашып қоюы мүмкін, сондықтан оларды тексеріп, қолжетімділікті бақылай отырып сақтау керек.

Контейнерлердегі басты тәуекел — құпияны образға «пісіріп тастау». Dockerfile-да ENV немесе ARG арқылы берілген кез келген нәрсе образ қабаттарында қалады және образды алған кез келген адамға қолжетімді. Оның орнына құпиялар қосымшаға іске қосылу сәтінде қоймадан беріледі, ал образ таза қалады.

Типтік қателер

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

Әзірлеуді тоқтатпай қалай көшу керек

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

Құпиялар қоймасы құпиясөз менеджерінен несімен ерекшеленеді

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

Қоймаға қатысты рөлдер мен процестер

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

Бәрінің жұмыс істейтінін қалай тексеру керек

Енгізгеннен кейін өзіңізге бірнеше сұрақты үнемі қойып, жауаптарын іс жүзінде тексерген пайдалы:

• Репозиторийлер мен образдардан кемінде бір әрекет етіп тұрған құпияны табуға бола ма? Иә болса, процесс аяқталмаған.
• Бұзылған кілтті ауыстыруға қанша уақыт кетеді және қанша жүйені қайта іске қосуға тура келеді?
• Қай қызметкерлер мен сервистер ең сезімтал құпияларды оқи алады және оларға бұл шынымен қажет пе?
• Кең қолжетімділігі бар қызметкер жұмыстан кетсе немесе оның тіркелгісі бұзылса, не болады?
• Журналда әдеттен тыс сұраулар көресіз бе: жаңа мекенжайлар, әдеттен тыс уақыт, қайталанатын бас тартулар?

Жауаптар қиындық тудырса, бұл қолжетімділік және ротация саясаттарын жетілдіру қажеттігінің белгісі. Үнемі жаттығулар, мысалы, кілттің ағуын имитациялау және оны жұмыс контурында ауыстыру, процестің регламентте жазылып қана қоймай, инцидентке шынымен дайын екенін көрсетеді.

Жиі қойылатын сұрақтар

Дереккөздер

• OWASP Secrets Management Cheat Sheet
• HashiCorp Vault: Lease, Renew, and Revoke
• HashiCorp Vault: Database secrets engine