Безопасное совместное использование облачной инфраструктуры

Мы рады объявить о возможности безопасного совместного использования инфраструктуры между учетными записями. Вы также можете определить, какие действия можно выполнять с этими общими ресурсами, что обеспечивает точный контроль. Эта новая функциональность позволит вам делиться различными наборами ресурсов с одной или несколькими другими учетными записями. Мы называем каждую такую политику списком контроля доступа (Access Control List) или сокращенно ACL. Вы можете создавать столько ACL, сколько вам нужно, в зависимости от ваших потребностей, а вносимые изменения применяются в реальном времени, поэтому они вступают в силу немедленно. Не говоря уже о том, что все ACL совершенно бесплатны для использования.

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

Ниже я прилагаю очень простое руководство, которое поможет вам настроить и запустить ваш первый ACL, а также видео на YouTube с обзором. Я сам использую их в своей учетной записи, чтобы делиться ресурсами с коллегами, поэтому уверен, что у вас также не возникнет проблем с началом работы. Кроме того, в конце я привел пару примеров того, как вы можете использовать новую платформу ACL.

Три простых шага для безопасного совместного использования

Итак, начнем. Мы разработали простой процесс из трех шагов для начала работы с ACL. Вы найдете новый раздел, который уже доступен в вашей учетной записи в веб-приложении:

Облачные ACL: безопасное совместное использование облачных ресурсов

Шаг 1: Создание тега

Во-первых, нам нужно настроить тег, чтобы определить, какими ресурсами мы хотим поделиться. Перейдите в раздел «Теги» (Tags) веб-приложения и нажмите кнопку ‘создать’. Предположим, мы хотим поделиться серверами баз данных, и создадим тег с именем database:

Создание нового тега облачной инфраструктуры

Теперь наш первый тег создан, и вы заметите, что в столбце ресурсов указано ‘0’, это означает, что мы еще не отметили тегами ни один ресурс:

Теги облачной инфраструктуры

Шаг 2: Добавление тегов к облачной инфраструктуре

Теперь перейдите в раздел вычислений (compute), чтобы выбрать серверы баз данных, к которым вы хотите добавить тег (обратите внимание, что если вы пометите тегом сервер, мы автоматически пометим все связанные с ним диски и сетевые политики):

Организуйте свои облачные серверы с помощью тегов

Теперь вы видите, что тег успешно добавлен к двум серверам баз данных:

Облачные серверы баз данных с новым тегом

Шаг 3: Создание списка контроля доступа

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

Создание ACL для вашей облачной инфраструктуры

Дайте имя вашей политике контроля доступа и настройте разрешения, которые вы хотите предоставить. Я собираюсь разрешить запуск/остановку (start/stop), открытие VNC (полезно для восстановления системы) и редактирование (для которого также требуется разрешение на просмотр списка/list). Я не буду разрешать подключение (attach) или клонирование (clone), поэтому политика больше направлена на управление сервером «как есть», а не на масштабирование или внесение серьезных изменений в настройки облачного сервера:

ACL младшего администратора баз данных

Теперь давайте добавим тег database к этому ACL:

Привязка тега к ACL

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

Добавление пользователей в ваш ACL

Примечание: Мы скрыли UUID в целях безопасности.

Наш ACL теперь активен и открывает доступ к настроенным нами ресурсам. Вернувшись к списку серверов, вы заметите, что перед именами серверов баз данных появился значок, указывающий на то, что в данный момент они активно используются совместно:

Облачные серверы с активным совместным доступом

Конечно, с другой стороны, общая облачная инфраструктура теперь должна появиться в учетной записи нашего администратора баз данных (в данном случае это другой сооснователь CloudSigma Патрик!):

Общие облачные серверы теперь видны

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

Диски общих облачных серверов

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

Сценарий использования 1: Внешний подрядчик

Возможно, вы сотрудничаете с внешним подрядчиком, разрабатывающим новую услугу, и хотите, чтобы у него был доступ к инфраструктуре, которой ему необходимо управлять для этого проекта, но вы не хотите давать ему полный доступ к вашей учетной записи и инфраструктуре CloudSigma. Используя ACL, вы теперь можете безопасно делиться с ними необходимой инфраструктурой без ущерба для безопасности. Все, что вам нужно сделать, это создать тег для проекта, назовем его Project X. Затем просто отметьте все ресурсы, которыми вы хотите поделиться, только что созданным тегом Project X. Наконец, перейдите в раздел ACL и создайте новый ACL. Решите, какими ресурсами вы хотите поделиться и какие действия им необходимо выполнять, и добавьте их учетную запись в ACL, указав их email и UUID (скорее всего, вам придется спросить у них их CloudSigma UUID). И вуаля — инфраструктура Project X автоматически появится в их учетной записи.

Теперь предположим, что проект готов или подрядчик уходит. Все, что вам нужно сделать, это удалить тег Project X с ресурса, и он больше не будет доступен для совместного использования, либо удалить внешнего подрядчика из ACL (вы можете добавлять в политику сколько угодно людей, поэтому вы можете захотеть сохранить политику, но исключить конкретного человека). Все очень просто.

Сценарий использования 2: Администратор баз данных

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

Например, предположим, что вы хотите разрешить администратору баз данных доступ только к серверам баз данных в вашей инфраструктуре. Это довольно просто: сначала создайте тег с именем ‘database’. Во-вторых, отметьте все ваши серверы баз данных этим тегом database. Наконец, создайте ACL, определяющий разрешения, которые вы хотите предоставить, добавьте только что созданный тег database, а затем добавьте данные учетной записи администратора баз данных в этот ACL. Готово.

Самое главное, если у вас появятся дополнительные серверы баз данных, к которым вашему администратору баз данных нужен доступ, все, что вам нужно сделать, это добавить тег database к этому серверу. Вот и все, разрешения будут автоматически передаваться из ACL в режиме реального времени, и ваш администратор баз данных увидит в своей учетной записи новый сервер баз данных, к которому у него есть доступ. Или, предположим, вы хотите закрыть доступ? Просто удалите тег database и т. д.

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

Приятной работы,

Роберт