как не забыть доступы, которые выдавал «на один вечер»

Временный доступ живёт дольше постоянного, если у него нет даты пересмотра. Как учитываете ключи и токены, которые выдавали для одной задачи? Не сами секреты в табличке, а кому выдали, зачем и когда проверить, нужен ли ещё доступ.

n1kita у меня в записи идентификатор ключа или токена, владелец, задача, область доступа и дата проверки. Сам секрет отдельно. Перед отзывом полезно проверить, не превратили ли его за это время в зависимость рабочего сервиса. Иначе уборка внезапно становится аварией.

lexa92 да, секреты отдельно. Ещё хочу к каждой записи ссылку на задачу: через месяц описание «тестовый ключ» не рассказывает вообще ничего.

n1kita добавлю к отзыву: не удалять наугад всё незнакомое сразу. Сначала связать идентификатор с владельцем и проверить зависимости, потом отзывать по одному с проверкой результата. Особенно если старый токен кто-то молча прописал в расписание.

lexa92 к проверке зависимостей: у многих сервисов в журнале видна дата последнего использования токена. Перед отзывом полезно свериться с ней: если обращений месяцами не было, кандидат на отзыв понятен, а если «мёртвым» ключом кто-то ходил вчера, сразу видно, кого искать. Это быстрее, чем расспрашивать всех по кругу.

n1kita, дата последнего использования помогает, но редкое задание может долго не обращаться к токену. Перед отзывом полезно проверить расписание и найти владельца интеграции. Простое ожидание жалоб после изменения прав не всегда ловит сбой вовремя. Есть ли у вас отдельный список, какой ключ используется каким заданием?

pavel_63 писал:
Есть ли у вас отдельный список, какой ключ используется каким заданием?

есть, но не отдельный. отдельная табличка у меня умирала трижды: заводишь её в апреле, к июню там «тестовый ключ 2» и ощущение, что вёл её вообще другой человек. теперь список живёт там же, где сам ключ. три места, все читаются за минуту.

комментарий прямо в compose над переменной:

environment:
  # токен подрядчика под разовый импорт каталога, задача OPS-412, гасить после 20.10
  IMPORT_TOKEN: ${IMPORT_TOKEN}

этот файл ты открываешь при каждом деплое, а табличку — никогда. дальше имя самого токена, если сервис позволяет: не «token1», а import-catalog-kill-20-10. через полгода в вебморде гитлаба или бакета не надо ничего вспоминать, владелец и срок прямо в названии. и у ssh-ключей комментарий при создании: ssh-keygen -C "petya-nout-kill-01-11". он сам едет в authorized_keys, и потом не нужна археология, чей это и когда резать.

про редкие задания — тут ты прав, и это отдельная боль. весной смотрю журнал: токен не ходил пять месяцев. кандидат на отзыв, отозвала. это оказался скрипт квартальной выгрузки для бухгалтерии. просыпался он ровно раз в квартал, пятницей утром, и вот однажды не проснулся. бухгалтер позвонила раньше мониторинга, что для самолюбия хуже любого алерта. так что дата последнего использования, про которую n1kita писал, теперь читается иначе: «не ходил полгода» — это не «мёртвый», это «спит». сначала идёшь и спрашиваешь владельца, потом режешь.

спящих перед отзывом ищу тупым поиском по расписаниям, вдруг кто молча прописал:

grep -r "IMPORT_TOKEN" /etc/cron.d /var/spool/cron /home 2>/dev/null
systemctl list-timers --all | grep -i import

не гарантия, но от повторной пятницы уже спасало.

а у тебя самого список есть, или как обычно «я и так помню»?)

n1kita про «мёртвым ключом ходили вчера» — для ssh это решается на сервере, а не опросом отдела. LogLevel VERBOSE в sshd_config, и в журнале остаётся отпечаток ключа, а не просто логин:

journalctl -u sshd --since "last week" | grep Accepted

сразу видно, каким именно ключом заходили.

kate_ekb с квартальной выгрузкой — знакомая история. у меня такие задания теперь при старте сами пишут строку в лог, чтобы между запусками о них было где узнать.

n1kita у меня за годы осталось одно правило: временный доступ рождается с датой смерти. Не «потом пересмотрю», а в момент выдачи. Где сервис умеет срок жизни токена — ставлю TTL и дальше он умирает сам, без моей памяти. Где не умеет — в тот же вечер создаётся задача на гашение с конкретной датой. Иначе «на один вечер» гарантированно переживёт и задачу, и подрядчика, и иногда сам сервер.

Проверено на себе. Весной разбирал authorized_keys на старой машине и нашёл ключ подрядчика, который делал разовую миграцию полтора года назад. Ключ рабочий, владелец давно не в проекте. Хорошо, что комментарий хоть был, а не дефолтный rsa-key-2024.

Плюс раз в месяц по cron простая сверка факта с записями — выгружаю комментарии всех ключей:

awk '{print $NF}' /home/*/.ssh/authorized_keys

и смотрю глазами на вывод, он короткий. Если там есть комментарий, которого нет в моём списке, значит ключ появился мимо меня. И это уже не вопрос учёта, а отдельный разговор.

n1kita ещё приём из той же серии: временный доступ не докладывать ключом к живому пользователю, а делать отдельного. contractor-ivan, свои ключи, свой sudo. Гашение тогда не «вспомни, какой из пяти ключей в authorized_keys был временным», а userdel -r — и хвостов ноль. Обжёгся на этом сам: резал «временный» ключ, снёс постоянный, потому что комментарии у обоих были дефолтные rsa-key.

lexa92 про отдельного пользователя взял на заметку, у меня обратная история: давал ключ другу на выходные, он помогал бота докрутить. Через полгода нашёл его в authorized_keys и уже не помнил зачем он. Спас комментарий, который при создании поставил, хоть какое-то воспитание у меня было)

А TTL где реально выставляется? У меня половина сервисов такого не умеет, и дата смерти живёт только в задаче, которую я сам себе завожу.

roman_krs писал:
А TTL где реально выставляется? У меня половина сервисов такого не умеет

Умеет больше, чем кажется. Гитлаб — expires_at при создании токена, дальше он умирает сам. У гитхаба fine-grained без даты вообще не создать. Для ssh вместо authorized_keys — сертификаты через ssh-ca, срок валидности внутри самого сертификата, истёк — и ключ мусор. А где сервис глухой, там at с командой гашения в момент выдачи. От собственной памяти отказался давно, она сроки не хранит.

lexa92 писал:
временный доступ рождается с датой смерти

дата смерти спасает от забывания. не от утечки. токен с expires_at через месяц, который сегодня оказался в репе, — это месяц чужого доступа, пока не ревокнешь руками. при компрометации TTL не ждём, режем сразу. дата — страховка от собственной памяти, не от сканера.

n1kita согласен, добавлю про сроки. Токен в публичном репе живёт минуты: сканеры мониторят коммиты в реальном времени, твой expires_at их не интересует. Сам видел — подрядчик запушил .env, через семь минут по ключу уже стучались с чужого asn. Порядок при компрометации один: сначала ревок, разбор потом. И после замены поднять логи за всё окно утечки, а не «поменял и забыл». Тишина в журнале — тоже ответ, но её проверяют, а не предполагают.

lexa92 писал:
такие задания теперь при старте сами пишут строку в лог

идея правильная, но она работает, если ты в этот лог смотришь до отзыва. я не смотрела — увидела «пять месяцев тишины» и отрезала. закончилось звонком из бухгалтерии в пятницу утром: выгрузка не ушла, зато я снова гений учёта). теперь правило: перед ревоком grep по журналу минимум за год, а не за месяц. квартальный скрипт за месяц не найдёшь, он терпеливее меня.

lexa92 писал:
временный доступ не докладывать ключом к живому пользователю, а делать отдельного

правильный рефлекс. у меня он же, только этажом ниже: временный доступ к данным — это не грант в боевой базе, а одноразовый контейнер. в прошлом месяце подрядчик разбирался, почему отчёт съезжает на две копейки. вместо «дам readonly на прод, потом не забуду отнять» подняла рядом копию:

services:
  reportdb:
    image: postgres:16
    restart: "no"
    environment:
      POSTGRES_PASSWORD: one-time-pass
    volumes:
      - ./dump.sql:/docker-entrypoint-initdb.d/dump.sql:ro
    ports:
      - "127.0.0.1:55432:5432"

перед заливкой дамп прогнала по телефонам и почтам — временный доступ это ещё и меньше данных, которые могут уехать не туда. дальше у него ssh-туннель до этого порта, до боя не добрался даже теоретически. закончил — docker compose down -v, и вспоминать, какие GRANT я там навыдавала, не нужно: база умерла вместе с томом. хвостов ноль, твой userdel -r вид сбоку.

по дате смерти. задачу на гашение я тоже заводила. и прощелкала её вместе со спринтом — задачи у меня умирают красиво, доступы почему-то нет. поэтому дата теперь живёт в самом ключе, в комментарии:

ssh-ed25519 AAAAC3... contractor-ivan-until-2026-11-01

два нюанса. пробелы в комментарии не ставлю — иначе твой awk по последнему полю покажет только «2026-11-01», и я полсверки буду гадать, чья это дата. и формат один на всех, чтобы месячная сверка превращалась в «просрочено / живёт» глазами, без календаря и без археологии в переписке.

roman_krs, задача — это обещание самому себе, дата в комментарии — свойство самого доступа. второе заметно сложнее прощелкать, проверено.

признавайтесь — у кого временное до сих пор помечено только в голове? тут безопасное пространство)

kate_ekb, до слова «одноразовая» всё спокойно прочитал, а на down -v остановился. я с томами ещё путаюсь, для меня тут лишняя буква — и уже страшно)

такую копию заведу отдельным compose-проектом с отдельными томами, чтобы хотя бы по названию видеть, что сейчас удаляю. а дамп для неё ты обычным pg_dump снимаешь или делаешь отдельную выгрузку для подрядчика?