Правильный способ размещения вашей организации в AWS

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

Используйте пользователей IAM для учетных записей сотрудников

Если вы уже использовали AWS, вы, вероятно, знакомы с пользователями IAM. По сути, это служебные учетные записи, используемые для аутентификации вещей, работающих на удаленных серверах, и предоставления им доступа к необходимым им ресурсам AWS (помещение вещей в корзину S3, запуск лямбда-функций и т. д.) без предоставления полного доступа к вашей основной учетной записи. Таким образом, если ваши серверы скомпрометированы (хакером или мошенническим сотрудником), злоумышленник будет иметь доступ только к тем разрешениям, которые вы предоставили.

Пользователи IAM великолепны, а также полезны для предоставления сотрудникам доступа к необходимым им услугам. Когда вы создаете пользователя IAM, у вас есть возможность включить доступ к консоли управления (в отличие от доступа CLI/API), что позволяет вам предоставить учетную запись сотруднику и предоставить ему доступ к консоли управления с ограниченными разрешениями. Вы даже можете включить многофакторную аутентификацию (MFA) для пользователей IAM с доступом к консоли, что сделает их очень безопасными.

Однако основная проблема заключается в том, что сотрудники, использующие учетные записи IAM, не смогут создавать своих собственных пользователей IAM без помощи корневой учетной записи. Если у вас есть менеджер проекта, которому необходимо предоставить безопасный доступ S3 PUT к приложению, он должен попросить владельца корневой учетной записи создать совершенно нового пользователя IAM специально для этого разрешения. Учитывая, что владельцем root-аккаунта обычно является владелец, технический директор или кто-то из высокопоставленных лиц, это огромная трата времени, особенно если вы даже не касаетесь производства.

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

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

Решение проблемы разной безопасности — AWS Organizations. Эта услуга позволяет вам управлять несколькими разными учетными записями под одной учетной записью root с единым выставлением счетов (пользователь root платит за каждую дочернюю учетную запись).

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

AWS Organizations предназначен для разделения среды разработки и рабочей среды. К каждой среде применяются разные правила; например, вы можете захотеть запретить сотрудникам создавать новых пользователей IAM, не используя все необходимые каналы и не консультируясь с начальством, но в процессе разработки необходимость проходить все эти проверки только замедлит разработчиков. Вы можете предоставить менеджерам проектов доступ к учетной записи разработки, чтобы ускорить тестирование.

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

Рекомендация AWS здесь, вероятно, такова, как должна выглядеть ваша организация. У вас есть основная производственная учетная запись, которая очень защищена и полностью доступна только высшему руководству. Среда «Тестовая» или «Промежуточная» функционирует как зеркало производства и доступна вашим инженерам по качеству и всем, кто выполняет тестирование, прежде чем вносить изменения в производство. Вы можете разделить их на две отдельные среды: test предназначен для автоматического тестирования с фиктивными данными (функционально расширение разработки, но более чистое), а staging — это полное зеркало производства, включая данные о клиентах и доступ к реальным общедоступным API.

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

Большинство ваших разработчиков, вероятно, работают с личными учетными записями IAM в среде разработки, что дает им гораздо более полный доступ, чем они могли бы получить в рабочей среде. Вы, вероятно, захотите дать своим разработчикам разрешения на использование большинства сервисов, которые вы используете в рабочей среде (просто следите за вещами, чтобы гарантировать, что использование находится под контролем).

Организационные подразделения (OU) также позволяют ограничивать разрешения каждой учетной записи с помощью политик управления службами (SCP). SCP во многом похожи на политики IAM, но на более высокий уровень — они применяются ко всей учетной записи под ними. Если учетная запись разработки создала пользователя IAM, который имел доступ к S3, но S3 не был включен в SCP, этот пользователь IAM не сможет использовать S3 в этой учетной записи. Услуги запрещены по умолчанию, поэтому вам нужно вручную внести их в белый список, чтобы иметь возможность их использовать.

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

Регулярно проверяйте безопасность вашей организации

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

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

Вам также необходимо убедиться, что разрешения SCP установлены правильно для каждой OU и не сильно меняются с течением времени. Вы не хотите, чтобы среда разработки могла арендовать 20 экземпляров c5d.24xlarge и резко увеличить ваш счет.