Шесть решений, которые стоит записать в договор доступа из облака к бэкенду

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

Решите операции до коннектора

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

Отделите данные, нужные отчёту, от данных, которые просто оказались доступны. Запишите разрешённые операции как конечные точки и глаголы в том же документе, что и решение об идентичности. Это различие и есть разница между интеграцией, которая проходит аудит, и той, которую приходится объяснять заново каждый год; оно же снимает споры позже без ещё одного совещания.

Решите идентичность рабочей нагрузки и назначьте ей владельца

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

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

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

Решите сетевой охват, зная, что это не разрешение

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

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

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

Решите обработку данных и разделение ответственности

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

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

Решите отказ, удаление и то, как вы это примете

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

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

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