Шифрование для MongoDB

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

Менее чем за десять лет компания MongoDB превратилась в ведущего поставщика нереляционных баз данных, превзойдя таких гигантов рынка систем управления базами данных, как Oracle Database и Microsoft SQL Server. В основе решения MongoDB лежит модель с малыми первоначальными операционными расходами и повышенной производительностью. Система управления базами данных компании стала одной из самых широко используемых в розничной торговле, финансовой сфере и здравоохранении.

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

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

Чтобы представить полную картину оптимальных путей развертывания и управления ключами шифрования в MongoDB, начнем с рассмотрения вариантов шифрования данных в базе данных MongoDB. Если вам нужно предварительно освоить принципы шифрования и управления ключами, то обратитесь к подробному руководству The Definitive Guide to Encryption Key Management Fundamentals (http://info. townsendsecurity. com/ebook-definitive-guide-to-encryption-key-management-fundamentals).

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

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

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

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

Если вы предпочитаете шифровать свои данные, имейте в виду, что MongoDB располагает решениями для шифрования как при пересылке, так и в хранилище.

Шифрование данных при пересылке

Для защиты пересылаемых данных все версии MongoDB поддерживают протоколы TLS (Transport Layer Security) и SSL (Secure Socket Layer) для приема и передачи данных по сети. TLS и SSL — варианты шифрования, широко используемые для защиты трафика веб-сайтов и обмена файлами. Это протоколы шифрования для защиты данных, пересылаемых из одной точки в другую; однако, прежде чем данные отправляются, и после того, как прибывают в конечную точку, они оказываются незашифрованными. MongoDB предоставляет обширную документацию по настройке протоколов TLS и SSL с использованием сертификатов и пары открытого и закрытого ключей (https://docs. mongodb. com/manual/tutorial/configure-ssl-clients/?jmp=partners_townsend), также именуемой системами асимметричных ключей.

В вопросе о шифровании пользователи MongoDB должны учитывать как государственные, так и частные требования к защите конфиденциальной информации. Например, индустрия платежных карт требует, чтобы номера кредитных карт в хранилище были зашифрованы. Закон об ответственности и переносе данных о страховании здоровья граждан и Закон о применении медицинских информационных технологий в экономической деятельности и клинической практике (HIPAA/HITECH) требуют электронной защиты информации о состоянии здоровья. Существует также много других нормативных актов, требующих надежной защиты персональных данных. Администраторы, в чьих базах данных хранятся конфиденциальные или персональные сведения, должны всегда шифровать базу данных MongoDB и использовать соответствующие средства управления ключами.

Шифрование данных в хранилище

Для шифрования неактивных данных в MongoDB Enterprise используется собственный механизм шифрования с симметричным ключом на основе хранилища на уровне файлов. Шифрование всей базы данных также именуется прозрачным шифрованием данных (TDE). Начиная с версии 3.2 MongoDB использует 256-разрядный алгоритм шифрования AES с единственным секретным ключом, применяемым для шифрования и восстановления данных. MongoDB также предоставляет возможность включить шифрование в режиме FIPS. Это означает, что механизм шифрования, используемый в MongoDB, протестирован Национальным институтом стандартизации и технологии (NIST) на соответствие Федеральному стандарту обработки информации (FIPS). Такие решения построены в соответствии со строжайшими стандартами и требованиями. Проверка алгоритма шифрования на соответствие NIST FIPS часто требуется для подрядчиков госучреждений и министерства обороны в Северной Америке; однако сегодня большинство регуляторов считают алгоритм AES с сертификатом NIST отраслевым стандартом. Как правило, регуляторы требуют, чтобы этот стандарт шифрования отвечал требованиям нормативных актов. Шифрование AES для неактивных данных доступно только в редакциях MongoDB Enterprise и Atlas с обязательной подсистемой хранилища WiredTiger.

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

Влияние на производительность

При необходимости шифровать базу данных MongoDB пользователи должны учитывать такую характеристику, как производительность. Снижение производительности может стать главной причиной беспокойства для пользователей MongoDB, хранящих большое количество данных, к которым потребители обращаются ежедневно через интерфейсные приложения. Когда приложение для банковской сферы или розничной торговли должно ежедневно вызывать миллионы записей из базы данных, любая задержка или простой могут серьезно повлиять на деятельность компании. Поэтому специалисты MongoDB выполнили тесты производительности на процессорах Intel Xeon X5675. При работе с максимальной нагрузкой средняя задержка подсистемы хранения с шифрованием составляет от 10 до 20%, в зависимости от количества данных, читаемых или записываемых пользователем в базу данных. Когда пользователь записывает в базу данных только большие объемы данных, влияние на производительность велико; однако гораздо чаще пользователь выполняет в основном команды только для чтения данных, и в большинстве организаций этот показатель составит, скорее всего, 5-10%.

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

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

Управление ключами шифрования в MongoDB

Шифрование ключей шифрования — метод, используемый для защиты и управления ключами шифрования. Термин «управление ключами» вызывает некоторую путаницу, поскольку простую запись ключа шифрования на липкой бумажке, которую прячут в выдвижной ящик стола, тоже можно рассматривать как управление ключом. Однако в контексте этой статьи под ним подразумевается то, что специалисты по безопасности данных называют корпоративным или профессиональным управлением ключами. Корпоративное шифрование ключей должно соответствовать инфраструктуре управления ключами и рекомендациям NIST, сформулированным в специальных публикациях SP-800-130 и SP-800-57.

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

MongoDB не располагает корпоративным решением управления ключами шифрования, и пользователям приходится покупать решение у стороннего поставщика. MongoDB позволяет пользователям управлять ключами шифрования с помощью стороннего поставщика через стандартный протокол управления ключами Key Management Interoperability Protocol (KMIP). KMIP поддерживается в выпусках MongoDB Enterprise и дает пользователям возможность защитить шифрование с помощью нескольких проверенных партнеров по управлению ключами шифрования.

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

Если вы ищете сторонние решения, которые помогут надежно управлять ключами, обязательно выясните, имеет ли сервер управления ключами (виртуальный или аппаратный) сертификат NIST FIPS140-2 и/или PCI. Эти сертификаты гарантируют, что программа управления ключами протестирована независимыми организациями и соответствуют высочайшим стандартам технологии управления ключами.

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

Корпоративное управление ключами

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

Элементы управления ключами

На технологическом и физическом уровне ключи шифрования следует хранить на логически или физически отдельном аппаратном или виртуальном сервере ключей, выделенном исключительно для управления ключами, в том числе для создания, хранения и распространения ключей. Диспетчер ключей должен располагать генератором псевдослучайных чисел с сертификатом FIPS140-2 для создания новых ключей и их хранения в защищенной базе данных ключей. Ключи, используемые для шифрования данных (DEK), должны быть обернуты и зашифрованы с использованием ключей шифрования ключа (KEK) — эти ключи используются только для расшифровки DEK внутри безопасной базы данных ключей.

Созданные ключи шифрования необходимо распространить для использования через безопасный протокол TLS с применением сертификатов для проверки подлинности пользователя, запросившего ключ шифрования. Корпоративный сервер управления ключами должен использовать последнюю рекомендованную версию TLS1.2, поскольку в версиях TLS1.1 и TLS1.0 были обнаружены уязвимости.

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

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

Жизненный цикл ключа шифрования

Важнейший административный компонент управления ключами шифрования — возможность управлять полным жизненным циклом ключа шифрования. NIST определяет все этапы жизни ключа, в том числе создание, предактивацию, активацию, распределение, отзыв, постактивацию, резервное копирование и удаление (рисунок 1).

Рисунок 1. Жизненный цикл ключа шифрования

Администраторы безопасности должны иметь возможность через административную консоль реализовать элементы управления, которые обеспечивают доступ к ключам, назначая ключи пользователям или группам пользователей. Кроме того, они должны иметь возможность назначать политики автоматической ротации ключа, чтобы ключи уничтожались или сменялись по истечении определенного времени. Эти элементы управления помогают организациям удовлетворять требования безопасности данных в некоторых регулируемых областях, таких как применение платежных карт. В стандарте безопасности данных в сфере платежных карт (PCI DSS) оговорены требования к управлению ключами для держателей или обработчиков карт. Удовлетворить их, как правило, можно только с использованием решения для управления ключами шифрования корпоративного уровня.

Элементы управления на основе политики

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

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

KMIP для централизованного управления ключами

Когда компания MongoDB решила реализовать KMIP, она ставила перед собой задачу помочь пользователям задействовать уже имеющееся у них корпоративное решение управления ключами или применить новое KMIP-совместимое решение.

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

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

Централизованное управление ключами в «облаке»

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

Рисунок 2. В целях повышения гибкости выбирайте поставщика EKM, успешно работающего в локальной, виртуальной и «облачной» среде

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

Соответствие нормативным актам

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

Однако нормативные акты в сфере защиты данных полезны, так как информируют клиентов, партнеров и заинтересованных лиц о том, что вы действительно внедрили различные инструменты безопасности для защиты не только своей информации, но и их данных. В последние 10 лет после нескольких резонансных краж данных стало ясно, что меры безопасности не существуют в вакууме, даже если кто-то полагает, что это так. Взаимосвязанная природа экономики, внутренняя и внешняя деятельность компаний и сети, обеспечивающие круглосуточную связь,?— все эти факторы способствуют тому, что становится все труднее закрыть все уязвимые места в наших системах. Небольшое нарушение в одной компании вполне может привести к катастрофическим последствиям в другой. Вспомните о взломе Target в 2013 году, когда злоумышленникам удалось проникнуть в сеть крупной розничной компании через сетевое соединение с ее поставщиком услуг отопления, кондиционирования и вентиляции.

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

Как и другие характеристики базы данных, MongoDB успешно справляется с шифрованием и управлением ключами шифрования. Предоставляя клиентам собственное шифрование AES на уровне базы данных и возможность использовать корпоративные решения управления ключами шифрования, проверенные Национальным институтом стандартизации и технологии (NIST), компания MongoDB помогает клиентам достичь нужного уровня безопасности и соответствия требованиям более простым способом, чем большинство ее конкурентов.

Национальный институт стандартов и технологии (NIST)

Оценивая решение для базы данных MongoDB вместе с решением управления ключами шифрования, важно учитывать наличие определенных сертификатов и проверок. В версии MongoDB Enterprise, как нам уже известно, используется алгоритм шифрования AES, проверенный на соответствие NIST. При выборе решений для управления ключами шифрования следует в первую очередь обратить внимание на проверки NIST FIPS140-2.

NIST FIPS140-2

NIST FIPS104-2 — стандарт NIST, в котором указаны требования безопасности для криптографических модулей FIPS PUB140-2. В этой публикации приведены требования к аппаратным и программным модулям, которые формируют выходные зашифрованные данные и используются для защиты данных. Эти требования охватывают алгоритмы шифрования, их реализацию, роли и проверку подлинности оператора, жизненный цикл ключа шифрования, физическую безопасность модуля и операционную систему. Уровни безопасности, которые могут быть назначены модулю, также определены и соответствуют физической безопасности модуля, в том числе компонентов с контролем вскрытия и несанкционированного изменения.

Системы управления шифрования ключей, успешно прошедшие проверку NIST FIPS140-2, тестировались на соответствие стандарту, подготовленному в рамках национальной программы добровольной аккредитации лабораторий (NVLAP), которая проводит тестирование и оценивает, в какой мере решение управления ключами шифрования соответствует стандарту NIST. Пройти эти тесты очень трудно, и требуются месяцы или годы, а также множество усовершенствований в модулях, чтобы достичь приемлемого результата. Решения управления ключами шифрования, прошедшие эти тесты, считаются лучшими в отрасли.

OASIS KMIP

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

Вторая и, вероятно, столь же важная сертификация, которую необходимо учитывать при оценке решения управления ключами шифрования для MongoDB, — протокол Key Management Interoperability Protocol (KMIP) организации OASIS. Этот протокол проектировался для того, чтобы упростить интеграцию функций управления ключами и дать клиентам возможность легко менять поставщиков услуг по управлению ключами. Такие поставщики программного обеспечения, как MongoDB, реализовавшие программный код KMIP на клиентской стороне и протестировавшие его на соответствие протоколу, могут интегрировать KMIP-совместимые серверы управления ключами без затрат на дополнительную разработку. Внедряя KMIP, компания MongoDB дает понять, что ее продукт не только совместим со многими решениями управления ключами шифрования корпоративного уровня, но и уважает желание клиентов выбрать предпочтительное для себя решение по критериям стоимости, гибкости развертывания или функциональности.

Стандарты и нормативы шифрования и управления ключами

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

PCI DSS: стандарты безопасности данных в сфере платежных карт — набор требований к безопасности данных, предъявляемых Советом по стандартам безопасности данных в сфере платежных карт к организациям, принимающим и обрабатывающим данные обладателей карт, в частности, номера кредитных карт и связанные с ними имена и адреса. В разделе 3 PCI DSS содержатся требования к протоколам шифрования и управления ключами шифрования.
Законы HIPAA и HITECH: Закон об ответственности и переносе данных о страховании здоровья граждан и Закон о применении медицинских информационных технологий в экономической деятельности и клинической практике содержат нормативы безопасности данных для здравоохранения. К сожалению, в HIPAA и HITECH нет четко оговоренного требования шифровать конфиденциальные данные, но понятие safe harbor косвенно указывает, что если в медицинской организации или у ее деловых партнеров происходит потеря данных, а защищенная медицинская информация (PHI) не скрыта с помощью шифрования или другого метода, то такая организация подвергнется строгому наказанию.
GLBA/FFIEC: закон Грэмма — Лича-Блайли, поддерживаемый американским федеральным советом по надзору за финансовыми учреждениями (FFIEC), требует, чтобы финансовые институты защищали конфиденциальную информацию клиентов. FFIEC четко оговаривает, что средства информационной безопасности должны соответствовать письменному плану защиты данных клиентов.
GDPR: в Евросоюзе (ЕС) не требуется, чтобы все организации немедленно шифровали конфиденциальные данные в рамках Общего регламента о защите данных (GDPR), но есть исключение для уведомлений о нарушениях субъекта данных и финансовые санкции для организаций, использующих шифрование и другие методы защиты данных.

К счастью для пользователей MongoDB во многих отраслях, простота реализации шифрования и инструментов управления ключами в конечном итоге поможет удовлетворить специфические требования большинства отраслевых нормативов по безопасности данных. Важно проверить, какие проверки и сертификации прошел поставщик средств управления ключами, чтобы без труда обеспечить соответствие требованиям. Обратите особое внимание на решения, проверенные на соответствие определенным нормативным актам, таким как PCI-DSS, поскольку эти проверки гарантируют, что технология испытана независимой лабораторией по строжайшим стандартам безопасности. Зачастую этого достаточно, чтобы ваше решение было признано соответствующим требованиям.

Непрерывность бизнес-процессов

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

Сегодня почти все компании широко используют программное обеспечение, и мысль о том, что ПО может внезапно оказаться недоступным, выглядит кошмарной. Критические компоненты основной деятельности предприятия всецело зависят от бесперебойной, мгновенной доступности как интерфейсных, так и внутренних программ на протяжении всего рабочего дня. Будь то программы терминалов продаж для обработки тысяч кредитных и дебетовых карт или база данных медицинских карт, из которой врачи ежедневно извлекают записи для сотен пациентов, важнейшие деловые операции почти целиком зависят от функциональности и доступности программного обеспечения. Когда при решении задачи непрерывности бизнес-процессов приходится учитывать шифрование и управление ключами шифрования, дополнительный уровень сложности часто пугает компании, которым предстоит внедрять эти инструменты. Системные администраторы спрашивают: «Что если шифрование снизит быстродействие систем? Что будет в случае потери ключей шифрования?» Это законные вопросы, но пользователи MongoDB могут быть уверены, что их база данных проектировалась с учетом подобных проблем, в полном соответствии с рекомендациями по обеспечению непрерывности бизнес-процессов и в сотрудничестве с поставщиками средств шифрования и управления ключами.

Зеркальное отображение в реальном времени

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

Балансировка нагрузки

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

Автоматический переход на другой ресурс

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

Автоматическое резервное копирование и ведение системных журналов

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

Гибридные развертывания

Самый широко распространенный тип развертывания серверов HA и рабочих серверов управления ключами шифрования предусматривает сочетание аппаратных, виртуальных и «облачных» вариантов. Причина этого в меньших начальных затратах и хорошей масштабируемости виртуальной и «облачной» сред. Пользователям MongoDB, предпочитающим сочетание аппаратного, виртуального и «облачного» развертывания своей базы данных и архитектуры высокой доступности, следует выбирать поставщика управления ключами, способного сделать то же самое. Важное преимущество развертывания как серверов MongoDB высокой доступности, так и серверов управления ключами высокой доступности в «облачной» или виртуальной среде, наряду с малыми затратами и более низким входным барьером, заключается в том, что «облачные» и виртуальные серверы HA можно развернуть в различных географических точках, чтобы избежать простоев, вызванных отказом сервера в одной географической точке. В Microsoft Azure эти географические точки именуются зонами доступности, а в Amazon Web Services — регионами (Region).

Автомасштабирование и управление ключами шифрования

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

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