API кључ је процурео: ротирање долази пре чишћења Git историје

Ако API кључ доспе у Git репозиторијум или CI лог, третирајте га као компромитован: припремите нови кључ, пребаците сервисе који га користе и опозовите стари. Проверу могуће злоупотребе започните одмах, а уклањање вредности из кода и логова нека не одложи опозив. GitHub-ово упутство за изложене тајне препоручује ажурирање сервиса који користе стари токен и проверу безбедносних логова, ако их добављач пружа.

Брисање низа из последњег commit-а мења само тренутну верзију датотеке. Старији commit, копија репозиторијума или сачуван CI излаз могу и даље да садрже исту вредност, док активан кључ и даље даје приступ. Временски оквири у наставку су редослед приоритета за реаговање, а не рок у ком сваки систем може безбедно да заврши ротацију.

Првих 15 минута: утврдите обим и ограничите приступ

Забележите ком добављачу кључ припада, које дозволе има, где се појавио и од када је то место било доступно. Проверите да ли је завршио у commit-у, захтеву за спајање измена, CI излазу или сачуваном артефакту. У белешке и поруке упишите идентификатор или маскирани део кључа, ако постоји, а не његову пуну вредност.

Пронађите власника кључа и људе који могу да измене његову конфигурацију. Одмах направите списак сервиса и процеса који га користе: продукциона апликација, тестно окружење, заказани послови, скрипте за распоређивање, CI променљиве и спољне интеграције могу користити исти кључ. Ако добављач дозвољава да привремено сузите дозволе или приступ, урадите то док припремате замену; такво ограничење не укида потребу за опозивом.

OWASP-ове смернице за управљање тајнама траже брзо ограничавање инцидента и хитан опозив изложеног кључа, уз ротацију, уклањање тајне и увид у логове. Ако постоји знак злоупотребе, опозовите стари кључ без чекања на потпун списак сервиса који га користе и прихватите могући прекид рада. Када је кратак прелаз изводљив без одлагања, припремите замену и брзо пребаците зависне сервисе пре опозива.

Први сат: пребаците сервисе и опозовите стари кључ

Направите нови кључ са најмањим дозволама потребним за посао који обавља. Сместите га у предвиђено складиште тајни или подешавања окружења и ажурирајте сваки унос са списка, укључујући CI променљиве и интеграције ван главне апликације. Проверите да ли је довољна промена конфигурације или сервис учитава кључ само при покретању, па захтева ново распоређивање.

1. Испробајте радњу која заиста користи нови кључ у сваком погођеном окружењу. Условни пример: успешан API позив из апликације не показује да је заказани посао добио нову вредност.
2. Опозовите или избришите стари кључ у систему добављача. Забележите време опозива и проверите статус ако га конзола приказује.
3. Пратите грешке ауторизације и неуспеле CI послове. Сервис који још користи стари кључ пребаците на нови, уместо да компромитовани кључ поново активирате.

Ако добављач не дозвољава да замена и стари кључ кратко постоје истовремено, унапред припремите измене конфигурације и контролисан тренутак преласка. Када је изложеност озбиљна, прекид зависног процеса може бити прихватљивија последица од остављања кључа активним. Та одлука треба да буде јасна власнику сервиса и тиму који води реаговање.

Проверите употребу од изложености до опозива

Проверу започните паралелно са заменом, а затим је довршите кад знате тачно време опозива. У логовима добављача потражите захтеве од најранијег познатог тренутка изложености: време, порекло, врсту операције и необичне грешке. Упоредите их са распоредом легитимних послова. Ако добављач не приказује употребу по кључу, забележите то ограничење и погледајте доступне логове саме апликације.

Проверите и где је вредност могла да остане доступна: у CI логовима и артефактима, захтевима за спајање измена, другим гранама и копијама репозиторијума. Ако уочите неовлашћене операције, укључите безбедносни тим и процените којим су подацима и системима дозволе кључа омогућавале приступ. Одсуство сумњивих записа ограничава налаз на оно што систем заиста бележи; није доказ да изложени кључ нико није видео.

Наредног дана: очистите записе и процените Git историју

Уклоните вредност из текућег кода, конфигурације и доступних артефаката процеса изградње, па проверите да је следеће распоређивање неће поново објавити. За CI логове и артефакте искористите могућности брисања или ограничења приступа које платформа пружа, уз очување података потребних за истрагу. Проверите и правило које је дозволило упис тајне у лог; маскирање и чување кључа ван кода смањују шансу да се исти пут излагања понови.

Преписивање историје је засебна одлука. GitHub-ово упутство за уклањање осетљивих података ставља опозив или ротацију испред тог поступка: преписивање мења идентификаторе commit-а, тражи координацију са сарадницима и само по себи не уклања вредност из туђих клонова, форкова или повезаних приказа. Пошто је стари кључ укинут, процените да ли преостали запис захтева такав захват или је ротација већ решила ризик приступа.

Ако се одлучите за преписивање, договорите поступак за погођене гране и клонове пре принудног слања нове историје. Стари клон може поново да унесе изложени commit ако сарадник настави рад без усклађивања. Упозорење о тајни затворите тек када потврдите опозив, прелаз зависних сервиса и уклањање вредности са места која су под вашом контролом.