Доступы и безопасность

Почему студии не нужен пароль от репозитория заказчика

Заказчик присылает логин и пароль от своего GitHub, студия хранит их до конца проекта и после. Заявка по ссылке решает то же самое: заказчик авторизует доступ сам, у себя.

Александр Цапков10 сентября 20262 мин

Обычный сценарий: студия берёт проект, где код принадлежит заказчику. Чтобы выкатывать, нужен доступ к репозиторию. Заказчик присылает логин и пароль — или токен — в переписке.

Дальше этот доступ живёт у студии до конца проекта. И после конца тоже.

Что не так с присланным паролем

Он не отзывается. Точнее, отозвать его может только заказчик, а он про него забудет через неделю после сдачи.

Он шире, чем нужно. Доступ к учётной записи — это доступ ко всем её репозиториям, а не к одному вашему.

Он лежит в переписке. Мессенджер, почта, тред с пятью участниками — везде, куда его переслали, он остаётся навсегда.

Он ваш риск, а не его. Если доступ утечёт из вашей папки, объясняться перед заказчиком будете вы, независимо от того, кто его туда положил.

Как мы это развернули

Подключение репозитория идёт заявкой по ссылке. Вы отправляете заказчику ссылку, он открывает её у себя и авторизует доступ в своём аккаунте.

Пароля вы не получаете вовсе — его негде хранить и нечего терять.

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

Что это меняет на практике

Пароль в перепискеЗаявка по ссылке
кто отзываетзаказчик, если вспомнитзаказчик, в своих настройках, в любой момент
объёмвся учётная записьто, что он выдал
где остаётсяв чате навсегданигде
чей рисквашраспределён

И отдельно — разговор при сдаче проекта. «Отзовите наш доступ» звучит совсем иначе, когда отзывать надо одну запись в настройках, а не менять пароль, который вы могли где-то сохранить.

Обратная сторона: доступы, которые заказчик всё-таки присылает

Панель хостера, регистратор домена, платёжный провайдер — там ссылки-заявки нет, и присылать придётся.

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

Смысл обеих механик один: секрет не должен появляться в мессенджере даже на минуту. Оттуда его уже не убрать.

Что из этого следует

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

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


Мы подключаем репозиторий заказчика заявкой, а серверы — агентом без ключей. Как устроен выкат — Деплой из Git.

Деплой из Git на свои серверыВыкат из git на свои серверы: домены, сертификаты, проверка здоровья, откат одной кнопкой.

Читайте также

Автор

Александр ЦапковОснователь Скоупворк

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