Управление доступом в IaaS: как разграничить права сотрудников

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

Что вообще значит «доступ» в облачной инфраструктуре?

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

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

Зачем бизнесу разграничивать права, если все свои?

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

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

Что такое принцип наименьших привилегий?

Это базовое правило информационной безопасности: каждому пользователю или сервису нужно давать ровно тот минимум прав, который необходим для работы, и не больше. Принцип сформулировали ещё в 1975 году в классической научной работе Джерома Зальцера и Майкла Шрёдера о защите информации в компьютерных системах, и с тех пор он остаётся одним из главных ориентиров при настройке доступа — как в IaaS, так и в любой другой цифровой системе.

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

Как устроена ролевая модель доступа в IaaS?

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

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

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

Можно ли дать доступ временно, а потом забрать?

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

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

Что делать с доступом уволенного сотрудника?

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

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

Как отследить, кто и что менял в облаке?

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

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

С чего начать компании, которая никогда не занималась доступом всерьёз?

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

В «Клауд АйСи» такие базовые настройки доступны прямо в панели управления облачными серверами: можно создавать роли, выдавать временный доступ подрядчикам и следить за журналом действий, не привлекая для этого отдельного специалиста по безопасности. Для большинства небольших и средних компаний этого набора уже достаточно, чтобы закрыть основные риски.