Блог Amazon Web Services

Реализация защищенной корпоративной системы резервного копирования и восстановления в AWS

Андрей Зайчиков, Архитектор AWS

Всем привет!

Сегодня мы поговорим о том, как реализовать защищенную корпоративную систему резервного копирования и восстановления с использованием сервисов AWS.

Для начала – пара слов о проблематике.

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

Очевидно, что системы резервного копирования и восстановления стоят денег, однако выделять деньги на подобные системы компании не спешат, т.к. стоимость данных решений в общем ИТ портфеле компании нередко довольно высока. Кроме того, для подобных систем характерны классические «железные» проблемы – неэффективное использование ресурсов, необходимость планировать ресурсы сильно заранее, сложность внедрения и сопровождения. В итоге, системы внедряются в ограниченном объеме (если вообще внедряются), что приводит к очевидным потерям в случае возникновения непредвиденных ситуаций.

Преимущества облачных технологий для данного класса систем кажутся очевидными, среди них можно отметить:

  • Практически неограниченный объем доступных ресурсов;
  • Использование ресурсов по pay-as-you-go модели;
  • Высочайший SLA по надежности и доступности;
  • Широкие возможности оптимизации хранения данных.

Однако, возникают резонные вопросы. Можно ли сохранить высокую степень конфиденциальности данных в облаке AWS? Можем ли мы быть уверенными, что данные не попадут в чужие руки / не будут повреждены / уничтожены? Можем ли мы гарантировать, что соединение нашей корпоративной сети с AWS безопасно? Насколько высока степень доступности, которую можно обеспечить? Насколько сильно удаленность региона повлияет на нашу работу? Получится ли выполнить архивирование / восстановление в заданный временной интервал? Насколько эффективно мы сможем использовать облачные ресурсы?

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

Пример для рассмотрения

Для начала сформулируем основные параметры сегодняшнего примера защищенной корпоративной системы резервного копирования и восстановления.

  • Общий объем данных резервного копирования — 50 TB
  • Скорость обновления данных — 0,5 TB в день
  • Частота создания резервных копий — 1 раз в неделю (выходные) / 48 часов
  • Особенности процесса обновления данных — Инкрементное обновление уже существующих данных (не более 4 TB в неделю)
  • RPO — 1 неделя (для основного массива резервных копий)
  • RTO — Архивные копии последних версий – по запросу, архивные копии предыдущих версий – в течение 6 часов после направления запроса (без учета времени на скачивание и расшифровку объекта)

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

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

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

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

  • [Cat1] Хранение в публичном облаке нежелательно в соответствие с внутренней политикой компании (например, резервные копии конфигураций программного обеспечения и оборудования СЗИ);
  • [Cat2] Хранение данных в публичном облаке возможно в случае, если метаданные об объекте хранятся на стороне Компании (например, резервные копии конфигураций приложений);
  • [Cat3] Хранение данных и метаданных в публичном облаке возможно (к примеру, резервные копии образов ВМ серверов).

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

Архитектура решения

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

Общее описание архитектуры решения

Упрощенное описание архитектуры решения представлено на схеме ниже. Данная архитектура состоит из следующих основных блоков:

  • Элементы инфраструктуры, которые производят данные, подлежащие резервному копированию (СХД, дисковые массивы серверов);
  • Транспортная инфраструктура, входящая в состав решения и обеспечивающая выполнение процедур резервного копирования и восстановления;
  • Инфраструктура шифрования и управления ключами, находящаяся внутри периметра организации;
  • Инфраструктура хранения зашифрованных данных, находящаяся в облаке AWS в одном из следующих регионов: eu-west-1 (Ireland), eu-west-2 (London) или eu-central-1 (Frankfurt, Germany).

Данная архитектура реализована в виде гибридной архитектуры с обеспечением доступа к системе хранения с использованием 2х основных вариантов:

  • Высокоскоростных выделенных каналов связи;
  • Средств импорта / экспорта физических носителей данных.

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

  • Объекты, подлежащие резервному копированию / восстановлению, не покидают периметр КСПД в незашифрованном виде;
  • Отдельные элементы транспортной инфраструктуры, обеспечивающие непосредственное взаимодействие с AWS, не имеют доступа к внутренним ресурсам КСПД;
  • Метаданные об объектах могут храниться как на стороне AWS, так и на уровне транспортной инфраструктуры подсистемы резервного копирования Компании;
  • Шифрование, резервное копирование и восстановление производится по объектам (например, резервная копия ВМ будет зашифрована как объект);
  • Обеспечение высокой доступности наиболее актуальных резервных копий (на уровне 99,9% — SLA для S3 Infrequent Access);
  • Обеспечение инкрементного обновления архивов и оптимизация затрат на хранение данных;
  • Надежность хранения резервных копий обеспечивается на уровне 99,999999999%.

Алгоритм работы решения

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

Выбор минимальной единицы резервного копирования / восстановления

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

Выбор методов и средств шифрования

В предлагаемой архитектуре управление ключами шифрования и выполнение процедуры шифрования объектов целиком находится в зоне ответственности заказчика. Данный подход позволит обеспечить максимально возможный уровень конфиденциальности информации в условиях хранения данных в публичном облаке. При этом дополнительно объекты могут быть зашифрованы стандартными средствами Server Side Encryption на стороне AWS (AES256, каждый объект шифруется своим ключом, ключи управляются AWS).

Выбор методов и средств организации подключения с облаку AWS

Подключение к публичному облаку – стандартная, хорошо описанная и часто выполняемая процедура. В данном решении у подключения к публичному облаку есть несколько ключевых аспектов, связанных, прежде всего с обеспечением высокой производительности каналов связи и максимального уровня информационной безопасности. Предполагается реализовать инфраструктуру шлюза чтения и записи в публичное облако с односторонним доступом (доступ к шлюзу осуществляется только со стороны транспортного сервера из КСПД Компании). Кроме того, предлагается организовать два выделенных канала производительностью 1 Gbps или 10 Gbps. Дополнительно, в случае необходимости, для повышения эффективности использования каналов связи можно применить средства WAN оптимизации. Передача данных по сети будет защищена с помощью L2 VPN.

При этом, если позволяют корпоративные политики информационной безопасности, возможно и прямое подключение КСПД Компании к облаку AWS.

Архивирование

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

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

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

  • Ведение реестра объектов, подлежащих резервному копированию;
  • Мониторинг сетевого раздела временного агрегирования данных на предмет появления новых объектов для сохранения;
  • Извлечение метаданных об объекте;
  • Интеграцию с внутрикорпоративной инфраструктурой шифрования объектов;
  • Безопасную интеграцию с компонентами шлюза обмена данными с облаком Amazon Web Services (передачу объекта на запись в облако AWS, передачу метаданных на запись в облако AWS);
  • Контроль процесса резервного копирования и восстановления данных;
  • Очистку дискового пространства по окончании процесса резервного копирования.

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

Сервера шифрования (или HSM) обеспечивает шифрование объектов с использованием собственных (любых) протоколов шифрования и собственных ключей шифрования. Управление ключами шифрования при этом осуществляется с использованием стандартных для организации политик и процессов.

После того как зашифрованный объект возвращается транспортному серверу он обеспечивает передачу объекта и его метаданных серверам записи в AWS.

Сервера записи в AWS обеспечивают запись объекта в Amazon Simple Storage Service (далее – S3) с использованием сервиса API S3, а также сохраняют метаданные объекта в DynamoDB для последующего использования. Необходимо отметить, что для использования S3 Endpoint внутри VPC потребуется по расписанию поднимать несколько EC2 машин, выполняющих функцию proxy для запросов записи в S3.

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

  • Настроена поддержка версий;
  • На добавление объектов должна быть настроена Lambda функция, которая будет проверять изменение версии объекта, выполнять перенос объекта из S3 в Glacier для оптимизации стоимости хранения и обновлять метаданные в таблицах DynamoDB.

Таким образом, при появлении новой версии объекта устаревшая версия будет либо перенесена в архивное хранилище (Glacier) для оптимизации расходов, либо уничтожена. Дополнительные настройки правил жизненного цикла данных обеспечат автоматическое удаление устаревших объектов.

Восстановление

Восстановление объектов из облака AWS инициируется пользователем через специализированный интерфейс (UI или API) программного обеспечения транспортного сервера. С помощью интерфейса пользователь сможет определить версию объекта, просмотреть его метаданные, а также ориентировочное время необходимое на восстановление объекта. Необходимо отметить, что в предлагаемой архитектуре метаданные будут храниться в AWS DynamoDB на стороне AWS (также можно организовать и локальное хранение метаданных на стороне серверов чтения / записи). Для получения данных из DynamoDB в целях обеспечения высокого уровня информационной безопасности и отсутствия прямого подключения КСПД Компании к AWS будет использоваться специализированный API серверов чтения данных из AWS.

После получения заявки на восстановление транспортный сервер направит эту заявку серверу чтения из AWS с использованием специализированного API.

Сервер чтения с AWS обеспечивает восстановление объекта из Glacier в S3 и его последующее чтение из S3 (либо чтение из S3 если была запрошена последняя версия объекта). По окончании чтения результат сохраняется на дисках сервера чтения и записывается в выходную очередь.

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

Сервисы AWS

Рассмотрим основные сервисы AWS, которые предполагается использовать в данном решении.

Amazon Direct Connect

Сервис предоставления выделенного физического канала от ЦОД заказчика до ближайшего региона AWS (Дублин / Франкфурт / Лондон). В рамках предлагаемой архитектуры планируется выделение 2х 1 Gbps портов, которые будут полностью находиться под контролем заказчика. Более подробная информация доступна по ссылке.

Amazon DynamoDB

Не реляционная база, предоставляемая как сервис. В данном решении будет являться базой метаданных об объектах, хранящихся в AWS. Хранение метаданных в БД (в отличие от хранения в тегах S3) удобно с точки зрения обеспечения быстрого поиска объекта, поиска объектов по условию и выполнения прочих операций, а также наличию возможностей по онлайн обработке данных (в том числе репликации в другие источники). Определение состава и структуры метаданных зависит от конкретного проекта, заказчика и данных. Один из вариантов заключается в том, что в качестве метаданных будет выступать уникальный кодификатор объекта и указатель на объект в S3. Связка объекта, сохраняемого в AWS с реальными метаданными будет храниться в БД в ЦОД заказчика (на уровне инфраструктуры шлюза данных) и не будет доступна из AWS. Более подробная информация о сервисе DynamoDB доступна по ссылке.

Amazon S3 (Infrequent Access)

Объектное хранилище, которое будет предоставлять основные возможности по записи, хранению и управлению зашифрованными архивными объектами текущего дня. Объект будет доступен к загрузке по требованию. Более подробная информация доступна по ссылке.

S3 поддерживает доступ через специализированные точки доступа внутри виртуальных подсетей в облаке, что сделает хранилище архивов доступным только из КСПД заказчика.

Amazon Glacier

Долговременное высоконадежное и эффективное с точки зрения стоимости хранилище. Данные будут попадать туда через S3 с использованием специализированных Lambda функций, которые будут отвечать за контроль версий, целостность данных, обновление метаданных об объекте и проч. Восстановление данных из Glacier может занимать несколько часов. Более подробная информация доступна по ссылке.

Обеспечение связи между ЦОД Компании и регионом

Реализация выделенных каналов связи

Выделенные каналы связи обеспечиваются провайдером услуг связи, который имеет партнерское соглашение с AWS. Партнер обеспечивает выделение и предоставление заказчику выделенных каналов и портов. Выделенные порты доступны в варианте 1 Gbps и 10 Gbps. Канал выделяется от ЦОД партнеров (есть партнеры с собственными мощностями в Москве и Санкт-Петербурге).

Порядок подключения следующий. Заключается договор с провайдером услуг связи, после чего он обеспечивает подключение заказчика к своим мощностям и каналам, ведущим до одного из ЦОД, скомутированных с регионом AWS. В данном ЦОД осуществляется физическое подключение выделенного порта, предоставляемого партнером к оконечной точке сервиса DirectConnect.

Реализация VPN туннелей

Подключение через L2 VPN организуется по стандартной процедуре между физическим сетевым оборудованием заказчика (или доверенного партнера) и сервисом Virtual Private Gateway со стороны AWS. Сформированный туннель поддерживает BGP, GRE и может быть построен с учетом необходимости обеспечения failover для канала связи.

Более подробно по процедуре организации VPN подключения можно прочитать здесь.

Оценка временного окна на выполнение процедуры резервного копирования

В данном разделе мы попробуем приблизительно рассчитать время необходимое на выполнение процедуры резервного копирования для ориентировочного недельного объема данных резервного копирования (3,5 TB). Резервное копирование будет проводиться в несколько основных шагов:

  • Формирование резервных копий и запись их на диск промежуточного хранения;
  • Выполнение шифрования объектов;
  • Выполнение передачи серверам записи в AWS;
  • Выполнение массовой параллельной загрузки в Amazon S3.

При расчетах в качестве среднего размера объекта определим 100Gb (образ виртуальной машины, файловый архив). Для расчета скорости шифрования берется практическая оценка скорости шифрования с помощью CryptoPro по 3DES – составляет 5 минут на 200 GB при использовании сервера с характеристиками 2 CPU & 8 GB RAM. Эти данные получены экспериментальным путем и могут не соответствовать фактической производительности в целевой системе. Ширина канала для передачи серверам записи в AWS, и собственно в AWS – 2x 1 Gbps.

  • Формирование резервных копий и запись их на диск промежуточного хранения — Около 3х часов в нормальной конфигурации дисков
  • Выполнение шифрования объектов — Около 4х часов
  • Выполнение передачи серверам записи в AWS — Около 2х часов
  • Выполнение массовой параллельной загрузки в Amazon S3 — Около 8ми часов
  • Итого общее время загрузки — 17 часов при нормальной загрузке систем / каналов (для инкрементной загрузки объектов)

Необходимо отметить, что более точный расчет по процедуре резервного копирования можно осуществить путем проведения пилотного проекта (Proof-of-concept) и его нагрузочного тестирования. Проведение такого тестирования возможно полностью на вычислительных мощностях AWS.

Отдельные аспекты технической реализации

Интеграция корпоративного ПО

Интеграция корпоративного ПО с решением по резервному копированию данных осуществляется на уровне записи / чтения данных с томов временного хранения, размещенных на корпоративном СХД с использованием стандартных интерфейсов СХД.

Обеспечение надежности и отказоустойчивости решения

Отказоустойчивости компонент на уровне основной части подсистемы хранения обеспечивается AWS в соответствие с SLA.

Отказоустойчивость части транспортной архитектуры решения может быть обеспечена несколькими основными способами:

  • Резервирование ресурсов на уровне ЦОД Компании и/или ЦОД доверенного партнера (для транспортных серверов, серверов чтения / записи, а также сетевой инфраструктуры) с применением стандартных средств обеспечения отказоустойчивости (в том числе настройки динамической маршрутизации, резервного копирования самих ресурсов и проч.);
  • Создание резервной площадки для обеспечения сетевого подключения к AWS. В таком случае сервера чтения и сервера записи могут быть развернуты также на резервной площадке либо в отдельной VPC AWS с использованием Amazon EC2 виртуальных машин.

Обеспечение управления решением

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

Управление физической инфраструктурой выполнения процедур резервного копирования и записи / чтения в AWS на уровне ЦОД и КСПД Компании и/или доверенного партнера осуществляется с помочью стандартных средств управления инфраструктурой.

Отдельные аспекты обеспечения информационной безопасности

В данном разделе мы коротко рассмотрим основные аспекты обеспечения информационной безопасности в предложеном решении.

Сетевая безопасность

Разделение на подсети

Согласно прилагаемой схеме, в решении используется три основных подсети:

  • Внутренняя DMZ КСПД Компании;
  • Внешняя DMZ КСПД Компании или сеть доверенного партнера;
  • Подсеть AWS VPC.

Доступа к внутренней DMZ КСПД Компании из любой другой подсети нет. Доступ из внутренней DMZ КСПД Компании осуществляется транспортным сервером по кастомизированным портам к внешней DMZ КСПД Компании или сети доверенного партнера. Сеть доверенного партнера подключается к AWS VPC через выделенный канал с настроенным L2 VPN.

Между всеми сетями (включая AWS VPC) настраиваются максимально жесткие правила межсетевого экранирования. Разрешения касаются только отдельных кастомизированных портов и IP адресов.

Межсетевые экраны

Правила межсетевого экранирования определяются на последующих этапах.

На уровне AWS VPC межсетевое экранирование включает в себя фильтрацию на уровне подсетей с использованием Network ACL (подробнее) и фильтрацию на уровне оконечных точек сервиса Security Groups (подробнее).

Системы предотвращения вторжений

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

На уровне КСПД и транспортной инфраструктуры должны быть включены системы IDS/IPS, рекомендованные политиками Компании.

Шифрование

Выполнение процедуры шифрования объектов, подлежащих резервированию

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

Контроль выполнения процедуры шифрования лежит на программном обеспечении транспортного сервера.

Все объекты, покидающие периметр КСПД должны быть зашифрованы в обязательном порядке.

Шифрование данных при передаче по сети

Шифрование данных при передаче между DMZ в которой находятся сервера чтения / записи и AWS будет осуществляться с использованием L2 IPSec VPN туннелей. Процедура создания туннелей и требования к оконечному оборудованию были описаны выше.

Шифрование данных при хранении в AWS

Дополнительно к сказанному выше возможно (и желательно) включение шифрования на стороне сервисов AWS. Server side encryption на уровне сервисов AWS поддерживает шифрование AES-256 с использованием отдельного ключа для каждого объекта. Ключи могут быть сгенерированы автоматически либо пользователем с использованием AWS Key Management Service.

Контроль целостности данных

Контроль целостности данных осуществляется на уровне транспортного сервера с использованием инструментов согласно внутренним политикам Компании. Запись информации для контроля целостности осуществляется до шифрования и после шифрования. Также осуществляется проверка целостности информации. Проверка целостности может осуществляться и на уровне сервисов AWS. Например, это можно реализовать с использованием механизма хранения MD5 Check Sum непосредственно в S3.

Разграничение доступа

Аутентификация пользователей, осуществляющих управление инфраструктурой

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

Первый способ – интеграция контроллера домена с Amazon Identity & Access Management путем установки SAML федерации. В таком случае права пользователей на доступ к ресурсам AWS будут устанавливаться политиками IAM, а фактическая аутентификация пользователей будет проводиться на уровне контроллера домена.

Интеграция контроллера домена, наиболее вероятно, потребует ввод нового контроллера на уровне серверов чтения / записи в AWS и его интеграцию с контроллером домена Компании и, с другой стороны, с Amazon IAM. Таким образом, пользователи будут аутентифицироваться в контроллере домена и получать корректные IAM Credentials для управления инфраструктурой. При этом основной контроллер домена будет лишь реплицировать данные в контроллер на уровне транспортной инфраструктуры и не будет доступен извне КСПД (обеспечен односторонний обмен информации).

Второй вариант – использование стандартных средств Amazon Identity & Access Management. Более подробно о возможностях Amazon IAM можно узнать здесь.

Аутентификация приложений на доступ к сервисам AWS

Приложения, которым необходим доступ к управлению ресурсами AWS (запись в endpoint S3) будут аутентифицироваться путем обращения к IAM Security Token Service (подробнее). При этом им будут выдаваться временные credentials и роль, для которой определена политика доступа только на запись / только на чтение к одной оконечной точке сервиса.

Разграничение доступа на уровне транспортных серверов

Разграничение доступа на уровне транспортных серверов осуществляется в соответствие с политиками безопасности организации в части доступа к дискам СХД. В части взаимодействия с средствами шифрования точные варианты реализации определяются при проектировании интеграции и зависят от доступных API и требований конкретных средств (серверов шифрования или HSM).

Мониторинг и логирование

Мониторинг канала и сетевого трафика

Мониторинг сетевого трафика на уровне выделенных портов и каналов осуществляется с использованием средств / инструментов, предоставляемых провайдером услуг связи.

Мониторинг сетевого трафика на уровне подсетей AWS VPC (от VPN до S3 endpoint) осуществляется с использованием предоставляемой AWS функции логирования сетевого траффика (AWS VPC Flow Logs). Более подробная информация доступна по ссылке.

Мониторинг обращений к API

Мониторинг обращений к API сервисов AWS (включая мониторинг манипуляций с объектами) будет осуществляться с помощью сервиса CloudTrail. Он обеспечивает логирование всех обращений к API. Дополнительно можно обеспечить нотификацию заинтересованных пользователей в случае выполнения определенных действий с объектами в системе хранения и/или другими ресурсами на стороне AWS. В первую очередь такой мониторинг обеспечивает контроль работы серверов записи и серверов чтения, а также выполнения жизненного цикла управления данными. Более подробная информация по сервису AWS CloudTrail доступна по ссылке.

Финансовые особенности решения

Все сервисы доступны по pay-as-you-go модели, когда оплата осуществляется по факту использования ресурсов. При этом для разных сервисов под ресурсами подразумеваются различные аспекты. Все без исключения цены доступны по публичному прайс листу. В нашем примере все цены расчитаны на момент подготовки материала для региона eu-west-1 IИрландия).

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

Правила формирования стоимости ресурсов для сервисов системы хранения

  • Объем хранения данных GB/мес
    • S3 IA — 0.0125$ за GB в месяц
    • Glacier — 0.007$ за GB в месяц
    • DynamoDB — $0.283 за GB в месяц
  • Входящий траффик — 0$
  • Исходящий траффик
    • S3 IA — $0.050 за GB за 350 TB/мес
    • Glacier — Восстановление из Glacier осуществляется в соответствие с ценовой политикой сервиса
    • DynamoDB — $0.090 за GB за 10 TB/мес
  • Количество запросов на запись
    • S3 IA — $0.01 за 1,000 запросов
    • Glacier — $0.055 за 1,000 запросов
    • DynamoDB — $0.00735 за час за каждые 10 единиц
  • Количество запросов на чтение
    • S3 IA — $0.01 за 10,000 запросов
    • Glacier — $0.055 за 1,000 запросов
    • DynamoDB — $0.00735 за час за каждые 50 единиц

Выполнение процедуры первичной загрузки данных

Процедура первичной загрузки данных будет существенно зависеть от того, сколько данных будет загружаться в S3 на еженедельной основе (инкремент размером ~3,5 TB или полный объем данных ~50 TB). Первичная загрузка имеет смысл только в случае, если на еженедельной основе будет загружаться инкремент (в противном случае первичная загрузка будет выполняться точно так же, как и еженедельная).

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

  • Первичная загрузка через быстрый выделенный канал;
  • Первичная загрузка с использованием сервиса Import/Export.

Первичная загрузка через быстрый выделенный канал

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

Выполнение процедуры осуществляется следующим образом:

  • На первом этапе обеспечивается временное выделение быстрого канала (2×1 Gbps) до указанного региона;
  • Данные шифруются внутри периметра Компании с использованием тех же серверов шифрования, которые будут использоваться для шифрования еженедельной загрузки данных;
  • Данные доставляются с помощью развернутой инфраструктуры резервного копирования;
  • По окончании начальной загрузки осуществляется замена обоих каналов на 1 Gbps.

Первичная загрузка с использованием сервиса AWS Import/Export

Данная процедура сложна с точки зрения логистики, а также предполагает наличие некоторого лага, в течение которого резервное копирование не осуществляется (пока основные данные не будут загружены).

Выполнение процедуры осуществляется следующим образом (пример для переноса данных в Ирландию):

  • Для полного объема данных обеспечивается извлечение метаданных по каждому объекту и формируется уникальный идентификатор (hash);
  • Данные шифруются внутри периметра Компании с использованием тех же серверов шифрования, которые будут использоваться для шифрования еженедельной загрузки данных;
  • Зашифрованные данные записываются на физические носители (диски – eSATA / USB);
  • Диски отправляются с помощью любой корпоративной службы доставки в Ирландию на адрес Amazon Web Services;
  • Сотрудники компании Amazon Web Services осуществляют загрузку данных в S3;
  • По окончании загрузки начинается выполнение рутинных процедур резервного копирования и восстановления;
  • Возврат пустых дисков осуществляется на юридическое лицо, зарегистрированное в ЕС.

Вместо послесловия

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

На сегодня все. Всем спасибо!

Следите за нашими обновлениями! Будет интересно!