Блог компании opsguru

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

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

Multitenant хранилища данных

Управлять multitenant данными удобно с помощью бункеров, Silo. Основная особенность разделение арендных данных (далее tenant) в multitenant решениях SaaS. Но перед тем, как поговорить о конкретных кейсах, затронем немного общей теории.

Доступ должен быть только у одного tenant

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

Отраслевые стандарты шифрования и безопасности

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

Настройка производительности на основании подписки tenant

Обычно, провайдеры SaaS рекомендуют общий рабочий процесс для всех tenant. С точки зрения практики, это не всегда может быть удобно по отношению к конкретной бизнес-логике. Поэтому можно сделать по-другом. Каждому tenant присваивают разные наборы свойств и пределы производительности в зависимости от стандарта TIER. Чтобы клиенты получали ту производительность, которая заявлена в соглашении SaaS провайдерам приходиться отслеживать использование индивидуальных tenant. Благодаря этому все клиенты получают равноценный доступ к ресурсам.

Управление данными

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

Как превратить обычное Хранилище данных в multitenant

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

• Соглашение об обслуживании;
• Шаблоны доступа для чтения и записи;
• Соответствие нормативам;
• Расходы.

Но есть ряд общепринятых практик разделения и изоляции данных. Рассмотрим эти кейсы на примере реляционной БД Amazon Aurora.

Секционирование tenant данных в общих хранилищах и инстансах

Таблица используется всеми tenant. Индивидуальные данные разделены и идентифицированы ключом tenant_id. Авторизация в реляционной БД реализована на уровне строк (row-level security). Доступ к приложению работает на основании политики доступа и учитывает конкретный tenant.

Плюсы:

• Это недорого.

Минусы:

• Авторизация на уровне базы данных. Это подразумевает несколько механизмов авторизации в рамках решения: AWS IAM и политики БД;
• Для идентификации tenant придется разработать логику приложения;
• Без полной изоляции невозможно обеспечить выполнение соглашения TIER об обслуживании;
• Авторизация на уровне БД ограничивает возможности отслеживания доступа с помощью AWS CloudTrail. Это можно компенсировать только добавлением информации извне. А лучше бы заниматься отслеживанием и устранением неполадок.

Изоляция данных на общих instance

Арендность (tenancy) по-прежнему расшаривается на уровне инстанса. Но при этом бункеризация данных происходит на уровне базы данных. Благодаря этому возможна аутентификация и авторизация AWS IAM.

Плюсы:

• Это недорого;
• За аутентификацию и авторизацию полностью отвечает AWS IAM;
• AWS IAM позволяет вести журнал аудита на AWS CloudTrail без костылей в виде отдельных приложений.

Минусы:

• Базовые инстансы БД шарятся между tenant, в связи с этим возможен отток ресурсов, что не позволяет полностью исполнить соглашение TIER об обслуживании.

Изоляция инстансов базы данных для tenant

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

Плюсы:

• AWS IAM обеспечивает как аутентификацию, так и авторизацию;
• Есть полноценный аудит;
• Четкое распределение ресурсов между tenant.

Минусы:

• Изоляция БД и инстансов среди tenant это дорого.

Как реализован доступ приложений к multitenant данным

Обеспечить правильный доступ приложений к данным важнее, чем хранить данные в модели арендной изоляции (tenant), которая соответствует бизнес-требованиям. Это не сложно, если использовать AWS IAM для управления доступом (см. примеры выше). Приложения, которые обеспечивают доступ к данным для tenant также могут использовать AWS IAM. Это можно рассмотреть на примере Amazon EKS.

Чтобы обеспечить доступ к IAM на уровне pod в EKS, прекрасно подойдёт OpenID Connect (OIDC), вместе с аннотациями к учетной записи Kubernetes. В результате произойдет обмен JWT с STS, что создаст временный доступ приложений к необходимым облачным ресурсам. При таком подходе нет необходимости вводить расширенные разрешения для базовых рабочих узлов Amazon EKS. Вместо этого можно настроить только разрешения IAM для учетной записи, связанной с pod. Это делается на основе фактических разрешений приложения, которое работает как часть pod. В итоге получаем полный контроль разрешений приложений и pod.


Интеграция IAM поддерживает комплексную систему авторизации для доступа tenant к хранилищам данных. В этом случае доступ к БД контролируется только через аутентификацию, а значит, нужно вводить еще один уровень безопасности.

Amazon EKS получает доступ к multitenant БД AWS DynamoDB

Пристальней посмотрим на multitenant доступ, как приложение, работающее на Amazon EKS, получает доступ к multitenant базе данных Amazon DynamoDB. Во многих случаях multitenant процессы в Amazon DynamoDB реализуют на уровне таблиц (в соотношении таблиц и tenant 1:1). Как пример рассмотрим принцип AWS IAM (aws-dynamodb-tenant1-policy), который отлично иллюстрирует шаблон доступа, где все данные связаны с Tenant1.

{   ...   "Statement": [       {           "Sid": "Tenant1",           "Effect": "Allow",           "Action": "dynamodb:*",           "Resource": "arn:aws:dynamodb:${region}-${account_id}:table/Tenant1"       }   ]}

Следующий шаг связать эту роль с учетной записью кластера EKS, которая использует OpenID.

eksctl utils associate-iam-oidc-provider \      --name my-cluster \      --approve \      --region ${region}

eksctl create iamserviceaccount \      --name tenant1-service-account \      --cluster my-cluster \      --attach-policy-arn arn:aws:iam::xxxx:policy/aws-dynamodb-tenant1-policy \      --approve \      --region ${region}

Определение pod, содержащее необходимую спецификацию serviceAccountName, поможет использовать новую учетную запись службы tenant1-service-account.

apiVersion: v1kind: Podmetadata: name: my-podspec:serviceAccountName: tenant1-service-account containers: - name: tenant1

Несмотря на то, что учетная запись и политика IAM tenant ориентированы, статичны и управляются с помощью таких инструментов, как Terraform и Ansible, спецификацию pod можно настроить динамично. Если вы используете генератор шаблонов, например, Helm, serviceAccountName можно установить в качестве переменной в соответствующие учетные записи tenant служб. В итоге у каждого tenant будет свое выделенное развертывание одного и того же приложения. Фактически, у каждого tenant должно быть выделенное пространство имен, где и будут запускаться приложения.

Заключение

Для SaaS-услуг важно хорошо продумать, как будет осуществляться доступ к данным. Следует учесть требования к хранилищу, шифрованию, производительности и управлению со стороны tenant. В multitenant нет какого-то одного предпочтительного способа разделения данных. Преимуществом выполнения multitenant рабочих нагрузок на AWS является AWS IAM, который можно использовать для того, чтобы упростить контроль доступа к tenant данным. К тому же, AWS IAM поможет настроить доступ приложений к данным в динамическом режиме.

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

Озера данных (data lakes) фактически стали стандартом для предприятий и корпораций, которые стараются использовать всю имеющуюся у них информацию. Компоненты с открытым исходным кодом часто являются привлекательным вариантом при разработке озер данных значительного размера. Мы рассмотрим общие архитектурные паттерны необходимые для создания озера данных для облачных или гибридных решений, а также обратим внимание на ряд критически важных деталей которые не стоит упускать при внедрения ключевых компонентов.

Проектирование потока данных

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

• Источники данных;
• Получение данных;
• Узел хранения;
• Обработка и обогащение данных;
• Анализ данных.

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



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


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

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


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

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

Компоненты платформы

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

Kubernetes отличный инструмент для такой работы. Он позволяет эффективно развёртывать, организовывать и запускать различные сервисы и вычислительные задачи озера данных надёжным и выгодным способом. Он предлагает унифицированный API, который будет работать и локально и в каком-либо публичном или приватном облаке.



Платформу можно условно разделить на несколько слоёв. Базовый слой это то место, где мы развертываем Kubernetes или его эквивалент. Базовый слой также можно использовать для обработки вычислительных задач вне компетенций озера данных. При использовании облачных провайдеров, перспективно было бы использовать уже наработанные практики облачных поставщиков (ведение журнала и аудит, проектирование минимального доступа, сканирование уязвимостей и отчетность, сетевая архитектура, архитектура IAM и т.д.) Это позволит достичь необходимого уровня безопасности и соответствия другим требованиям.

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

Уровень озера данных включает в себя все необходимые сервисы для приёма (Kafka, Kafka Connect), фильтрации, обогащения и переработки (Flink и Spark), управления рабочим процессом (Airflow). Помимо этого, он включает хранилища данных и распределённые файловые системы (HDFS), а также базы данных RDBMS и NoSQL.

Самый верхний уровень получение значений данных. По сути, это уровень потребления. Он включает в себя такие компоненты, как инструменты визуализации для понимания бизнес-аналитики, инструменты для исследования данных (Jupyter Notebooks). Другим важным процессом, который происходит на этом уровне, является машинное обучение с использованием обучающей выборки из озера данных.

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

Взаимодействие компонентов платформы

Кластер Kafka будет получать неотфильтрованные и необработанные сообщения и будет функционировать как узел приёма в озере данных. Kafka обеспечивает высокую пропускную способность сообщений надёжным способом. Кластер обычно содержит несколько разделов для сырых данных, обработанных (для потоковой обработки) и недоставленных или искажённых данных.

Flink принимает сообщение из узла c необработанными данных от Kafka, фильтрует данные и делает, при необходимости, предварительное обогащение. Затем данные передаются обратно в Kafka (в отдельный раздел для отфильтрованных и обогащенных данных). В случае сбоя, или при изменении бизнес-логики, эти сообщения можно будет вызвать повторно, т.к. что они сохраняются в Kafka. Это распространенное решение для в потоковых процессов. Между тем, Flink записывает все неправильно сформированные сообщения в другой раздел для дальнейшего анализа.

Используя Kafka Connect получаем возможность сохранять данные в требуемые бекенды хранилищ данных (вроде золотой зоны в HDFS). Kafka Connect легко масштабируется и поможет быстро увеличить количество параллельных процессов, увеличив пропускную способность при большой загрузке:



При записи из Kafka Connect в HDFS рекомендуется выполнять разбиение контента для эффективности обращения с данными (чем меньше данных для сканирования тем меньше запросов и ответов). После того, как данные были записаны в HDFS, serverless функциональность (вроде OpenWhisk или Knative) будет периодически обновлять хранилище метаданных и параметров схемы. В результате, к обновленной схеме становится возможно обращаться через SQL-подобный интерфейс (например, Hive или Presto).



Для последующего data-flows и управления ETL-процессом можно использовать Apache Airflow. Он позволяет пользователям запускать многоступенчатые pipline обработки данных с использованием Python и объектов типа Directed Acyclic Graph (DAG). Пользователь может задавать зависимости, программировать сложные процессы и отслеживать выполнение задач через графический интерфейс. Apache Airflow также может служить для обработки всех внешних данных. Например, для получения данных через внешний API и сохранения их в постоянном хранилище.

Spark под управлением Apache Airflow через специальный плагин, может периодически обогащать сырые отфильтрованные данные в соответствии с бизнес-задачами, и подготавливать данные для исследования специалистами по данным, и бизнес-аналитикам. Специалисты по данным могут использовать JupyterHub для управления несколькими Jupyter Notebook. Поэтому стоит воспользоваться Spark для настройки многопользовательских интерфейсов для работы с данными, их сбором и анализом.



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

Если сложить пазл воедино, мы получим что-то вроде этого:

Операционное совершенство

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

Основные принципы будут следующими:

1. Ограничить доступ пользователей;
2. Ведение мониторинга;
3. Шифрование данных;
4. Serverless-решения;
5. Использование процессов CI/CD.

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

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

Шифрование данных ещё один механизм для защиты данных. Шифрование хранимых данных может производиться при помощи системы управления ключами (KMS). Это зашифрует вашу систему хранения и текущее состояние. В свою очередь, шифрование при передаче может производиться при помощи сертификатов для всех интерфейсов и эндпоинтов сервисов вроде Kafka и ElasticSearch.

А в случае систем поиска, которые могут не соответствуют политике безопасности, лучше отдавать предпочтение serverless-решениям. Необходимо также отказаться от ручных деплоев, ситуативных изменений в любом компоненте озера данных; каждое изменение должно приходить из системы контроля версий и проходить серию CI-тестов перед развертыванием на продуктовое озеро данных (smoke-тестирование, регрессия, и т. д.).

Эпилог

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