ru

Кому должны принадлежать AWS, GitHub и боевые аккаунты?

Короткий ответ

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

Распространённая схема — подрядчик заводит аккаунты, подрядчик платит, подрядчик выдаёт вам доступ — в начале выглядит удобно и тихо превращает обычный коммерческий спор в операционную аварию. Исправление — это административная работа, а не конфронтация, и до спора она стоит несопоставимо дешевле, чем после.

Как это выглядит на практике

Платёжный продукт работал два года, когда отношения с подрядчиком закончились. Код принадлежал компании. Аккаунт AWS, домен, TLS-сертификаты, проект в системе мониторинга и аккаунт платёжного провайдера были оформлены на организацию подрядчика. Проблема была не в коде.

Чек-лист

Репозиторий и контроль версий

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

Облачные аккаунты и root-доступ

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

Домен и DNS

Аккаунт регистратора ваш, администратором домена указана компания, а DNS находится там, где вы можете поменять запись сегодня. Домены теряют из-за неоплаты и недоступного почтового ящика куда чаще, чем из-за споров.

Доступ в продакшн и его список

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

База данных и выгрузка

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

Резервные копии и восстановление

Где лежат копии, кто может восстановить, на какую глубину и восстанавливали ли хоть раз. На чьём аккаунте они лежат — так же важно, как существуют ли они вообще.

Сторонние сервисы и провайдеры

Идентификация и KYC, платежи и выплаты, почта, SMS, мониторинг, сбор ошибок, аналитика. У каждого — владелец и способ оплаты, и каждый является отдельной маленькой зависимостью, которая либо у вас, либо нет.

Документация и знания

Регламенты, архитектурные заметки и решения хранятся там, где вы этим управляете, а не в вики подрядчика. Знание, которое живёт только в чужом инструменте, вам не принадлежит.

Зависимость от конкретного человека

Посчитайте, сколько ответов выше сводятся к одному конкретному человеку — с любой стороны. Это число и есть ваш настоящий риск непрерывности, и обычно оно выше, чем следует из оргструктуры.

Чего этот ответ не покрывает

  • Схема, в которой подрядчик действительно эксплуатирует инфраструктуру, бывает правильным выбором. Проблема в том, чтобы прийти к ней по умолчанию, а не решением.
  • Владеть аккаунтами не значит их администрировать. Можно владеть корневым аккаунтом и делегировать всю эксплуатацию.
  • Это чек-лист контроля, а не оценка безопасности. Правильное владение ничего не говорит о том, насколько корректно настроено внутри.
  • В части регулируемых сфер к доступам, разделению полномочий и хранению записей предъявляются собственные требования, выходящие за рамки этого списка. Их нужно проверять отдельно.