Создание Web-приложения, отвечающего требованиям безопасности данных

Оптимизация использования ресурсов для защиты данных разного типа

В большинстве организаций конфиденциальными считаются примерно 25% всех типов данных. В связи с этим возникает вопрос: стоит ли проектировать облачное приложение так, чтобы использовать 100% имеющихся ресурсов безопасности для защиты всех типов данных? Это расточительный метод; но существует другой. В этой статье рассматриваются три категории данных организации, а затем с помощью этой классификации определяется способ защиты каждого типа данных при разработке приложений, использующих эти данные. Автор называет такой подход Regulatory Compliant Cloud Computing (RC3).

Аршад Нур, технический директор, StrongAuth Inc.

Аршад Нур (Arshad Noor) ― технический директор расположенной в Кремниевой долине компании StrongAuth Inc., которая в последнее десятилетие специализируется на корпоративных решениях для управления ключами шифрования. Имеет 25-летний опыт работы в сфере ИТ; последние 12 лет занимался внедрением инфраструктуры управления ключами шифрования для защиты конфиденциальных данных в десятках стратегически важных систем в разных странах.



09.11.2012

Появление облачных вычислений в качестве альтернативы стратегии развертывания собственных ИТ-систем создает много новых возможностей, но при этом традиционно ставится вопрос о безопасности данных. Появляются все новые правила безопасности данных, и ИТ-специалисты ломают голову над тем, как воспользоваться преимуществами облачных вычислений и в то же время доказать соответствие нормативным требованиям по защите конфиденциальной информации. (Например, компании TJX и Heartland Payment Systems заплатили в общей сложности более 220 млн долл. штрафа и компенсаций за утечку информации о 94 млн и 130 млн кредитных карт в 2007 и 2009 гг. соответственно. На сегодняшний день это крупнейшие из обнародованных случаев утечки конфиденциальных данных из компьютерных систем.)

Существует много подходов к решению этой проблемы; вот полярные позиции:

  • вообще не использовать облако;
  • полностью перейти на облачные вычисления.

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

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

Традиционная архитектура Web-приложения

Концептуально Web-приложения просты. Браузер — клиентская часть соединения клиент-сервер — отображает форму и запрашивает данные у пользователя. Сервер представляет собой программное обеспечение, исполняемое на том или ином сервере Web-приложений. После отправки формы пользователем серверная программа получает и обрабатывает информацию, а затем возвращает ответ, основанный на результате операции. Это взаимодействие показано на рисунке 1.

Рисунок 1. Стандартная архитектура Web-приложения
Стандартная архитектура Web-приложения

Хотя в зависимости от того, какие задачи выполняют приложения, модель может быть очень сложной, у них есть одна общая черта: Web-форма должна содержать универсальный указатель ресурса (URL) сервера, чтобы браузер знал, куда отправлять данные формы.

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

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

Рисунок 2. Переадресация в платежную систему
Переадресация в платежную систему

Недостатки существующего способа инвестиций в ИТ

У существующего подхода к инвестициям в ИТ много недостатков. Если в качестве примера взять типичное приложение электронной торговли, то при текущем режиме инвестиций в ИТ компания должна действовать по следующей схеме.

  1. Приобрести физические ресурсы — для вычислений, хранения данных и сетевых операций — с учетом всех функций приложения:
    • регистрация клиента;
    • управление товарами и услугами;
    • учет;
    • операции купли-продажи;
    • обработка платежей;
    • выполнение заказов.
    И многое другое. Обычно спустя несколько лет это приводит к дополнительному бремени по модернизации установленной инфраструктуры, так как она устаревает и отстает от потребностей в части производительности.
  2. Обеспечить избыточность вычислительной инфраструктуры для гарантии непрерывности бизнеса — обычно это означает удвоенные инвестиции в инфраструктуру.
  3. Обеспечить защиту всей инфраструктуры. Поскольку большинство предприятий не делают различий между секретными и несекретными данными, система безопасности обычно применяется ко всем компонентам инфраструктуры и данных. Это нерациональное использование ресурсов, поскольку несекретная информация не нуждается в такой же защите, как конфиденциальная. (В последние несколько лет ввиду появления стандарта PCI-DSS [стандарт безопасности данных индустрии платежных карт] предприятия стали различать «PCI-зону» и «не-PCI зону», «PCI-данные» и «не-PCI данные». PCI-зоне и данным обычно уделяется больше внимания и инвестиций с точки зрения безопасности, чем их не-PCI собратьям. Это можно рассматривать как форму оптимизации, так как PCI-зона находится во внутренней сети предприятия, однако оно по-прежнему тратит на защиту данных больше средств, чем в случае использования той архитектуры приложения, которая описана в этой статье.)

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

Появление облака меняет подход к инвестированию

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

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

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


Удовлетворение нормативных требований при облачных вычислениях

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

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

Я называю эту архитектуру Regulatory Compliant Cloud Computing (RC3) (нормативно-соответствующие облачные вычисления): модель вычислений, при которой операции охватывают регламентируемые зоны и публичные облака. Конфиденциальные данные шифруются, снабжаются маркерами и администрируются в регламентируемой зоне внутренней сети предприятия (или делегируются специализированной компании), а все остальные помещаются в публичное облако. Этот подход иллюстрируется на рисунке 3.

Рисунок 3. Модель архитектуры Regulatory Compliant Cloud Computing
Модель архитектуры Regulatory Compliant Cloud Computing

Далее мы рассмотрим классификацию данных в архитектуре RC3, а затем ― порядок выполнения транзакций при различных сценариях работы в структуре RC3.

Классификация данных для RC3

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

Рассмотрим классификацию RC3.

Класс 1/C1: состоит из конфиденциальных и регламентируемых данных. Это данные, раскрытие которых приведет к штрафам, потенциальным судебным искам и потере доверия к нарушившей организации. Примерами данных класса 1 служат номера кредитных карт, номера социального страхования, номера банковских счетов и другие подобные данные.

Класс 2/C2: состоит из деликатных, но нерегламентируемых данных. Это данные, которые не регламентируются нормативными документами, но их раскрытие причинит ущерб компании и/или приведет к некоторой потере доверия к ней. Примерами данных класса 2 служат данные о заработной плате работника; показатели продаж конкретных семейств изделий; имя, пол и возраст клиента, и т.д.

Класс 3/C3: состоит из неконфиденциальных данных. Иными словами, это любые данные, не относящиеся к категориям C1 и C2. Например, описания продуктов, их изображения и т.д.

Следует отметить, что класс данных может меняться: когда конфиденциальные данные маркируются в хорошо продуманной системе шифрования и управления ключами (EKM), их фактически можно считать неконфиденциальными. В этом случае даже данные C1/C2 после шифрования и маркировки можно классифицировать как данные C3.

Основываясь на этих классификациях, компании, внедрившие RC3, гарантируют:

  • что все данные C1 будут обрабатываться и храниться в регламентируемых зонах внутри защищенной сети. Эти зоны соответствуют требованиям безопасности, предъявляемым регулирующими органами. Маркеры данных C1 (конфиденциальные данные, зашифрованные и замененные маркерами) могут храниться в публичных облаках;
  • все данные C2 будут обрабатываться в безопасной, но не обязательно регламентируемой зоне. Маркеры данных C2 могут храниться в публичных облаках;
  • все данные C3 могут обрабатываться и храниться в публичных облаках.

Приложения должны учитывать это разделение данных; но архитектура Web-приложений — особенно возможность перенаправлять браузер на целевые серверы — обладает всеми характеристиками для поддержки этой модели.

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

Транзакция электронной торговли RC3

В качестве схематического примера транзакции электронной торговли RC3 я описываю сценарий с использованием модели Java™-приложения, но нужно понимать, что эта модель не является исключительно Java-моделью и ее можно легко перенести на .NET или реализовать с помощью любых языков сценариев, таких как PHP, Ruby и т.д. Кроме того, если в примерах используются Amazon Web Services (AWS), то это просто для иллюстрации; модель легко реализуется в любых общедоступных облачных инфраструктурах, таких как Azure, vCloud, IBM® SmartCloud и т.д.

Регламентируемая зона состоит из демилитаризованной зоны компании (DMZ) и безопасной зоны (SECZ). Сервер Web-приложений находится в DMZ и принимает соединения пользователей через Интернет. Он связывается с сервером базы данных и инфраструктурой управления ключами предприятия (EKMI), которые находятся в SECZ. EKMI отвечает за шифрование, маркировку и управление ключами для всех данных C1 и C2. EKMI должна располагать всеми элементами управления, необходимыми для соблюдения правил безопасности данных. Все сообщения передаются через TLS/SSL.

Зона публичного облака (PBZ) состоит из сервера Web-приложений и хранилища данных. Сервер Web-приложений принимает соединения пользователей из Интернета, а также запросы Web-сервисов от Web-сервера приложений в DMZ. Все сообщения передаются через TLS/SSL. Запросы Web-сервисов из DMZ к публичному облаку дополнительно защищены SSL ClientAuth для взаимной проверки подлинности между конечными точками.

Транзакции этого типа состоят из следующих шагов.

  1. Пользователь регистрируется в качестве клиента в регламентируемой зоне и получает уникальный идентификатор клиента (CID), который рассматривается как данные C3. Контактная информация клиента обозначается как данные C2, а сведения о его заказе ― данные C3. Данные C2 шифруются, маркируются и хранятся в EKMI. Все данные C3 хранятся в PBZ и передается через SSL-соединение с проверкой подлинности клиента вместе с данными сеанса этой транзакции. См. Шаг 1 на рисунке 4.
    Рисунок 4. Этапы транзакции электронной торговли RC3
    Этапы транзакции электронной торговли RC3
  2. На этом этапе браузер пользователя перенаправляется в PBZ, где обрабатывается большая часть транзакции.
    1. Просмотр каталога продуктов.
    2. Определение их цен и наличия в продаже.
    3. Добавление выбранных продуктов в корзину.
    4. Отображение инструкций по доставке.
    5. И любые другие данные, не связанные с оплатой.

    Заголовки запроса переносят маркеры сеанса, присвоенные сервером Web-приложений в DMZ; это обеспечивает соответствие между данными транзакций в PBZ и той же транзакцией в регламентируемой зоне. См. Шаг 2 на рисунке 4.

  3. Когда пользователь готов оплатить покупку, браузер перенаправляется на DMZ-сервер компании, где пользователь вводит данные кредитной карты для оплаты. После подтверждения транзакции конфиденциальные данные C1 шифруются, маркируются и сохраняются в EKMI. После маркировки данные C3 сохраняются в PBZ посредством запроса Web-сервиса с проверкой подлинности клиента. См. Шаг 3 на рисунке 4.

    Некоторые замечания по безопасности транзакции электронной торговли:

    • соблюдение правил безопасности данных обеспечивается тем, что конфиденциальные и регламентированные данные шифруются и сохраняются EKMI в безопасной зоне;
    • PBZ не хранит никаких учетных данных пользователя. Проверка подлинности пользователя выполняется в регламентируемой зоне, этому пользователю присваивается действительный маркер сеанса, и браузер пользователя перенаправляется в PBZ для дальнейшей обработки;
    • связь между DMZ и PBZ поддерживается только в одном направлении, от DMZ к PBZ. PBZ никогда не взаимодействует с серверами в регламентируемой зоне; если приложение разработано надлежащим образом, то в этом нет необходимости. Это гарантирует, что никакой взлом PBZ никогда не затронет регламентируемую зону;
    • серверы в регламентируемой зоне взаимодействуют с PBZ только через Web-сервисы SSL с проверкой подлинности клиента. Это позволяет избежать необходимости хранить какие-либо учетные данные для проверки подлинности в PBZ. (Для проверки подлинности клиента SSL требуется хранить на целевом компьютере только действительный и пользующийся доверием цифровой сертификат для аутентификации соединения с клиентом. Однако клиент должен обладать действительным секретным ключом к цифровому сертификату и участвовать в протоколе аутентификации клиента SSL.)

RC3 транзакция в сфере здравоохранения

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

Транзакции этого типа состоят из следующих шагов.

  1. Техник рентгеновского кабинета проходит проверку подлинности на серверах регламентируемой зоны клиники и устанавливает сеанс связи. Если нужно создать новые данные для пациента, то это делается в регламентируемой зоне, где пациенту присвоен ID (PID). Некоторые элементы демографических данных пациента обозначаются как данные C1/C2; так что EKMI шифрует и маркирует их. Клиника может хранить маркированные данные C1/C2 в регламентируемой зоне или в PBZ с использованием безопасного одностороннего Web-сервиса в облаке. См. Шаг 1 на рисунке 5.
    Рисунок 5. Этапы операции RC3 в сфере здравоохранения
    Этапы операции RC3 в сфере здравоохранения
  2. Браузер техника перенаправляется в PBZ, где выполняются неконфиденциальные части операции:
    • регистрация даты и времени визита;
    • запрос идентификатора врача и направления на рентгенографию;
    • посещение рентгеновского кабинета и проведение процедуры;
    • запись любых других неконфиденциальных данных.

    Приложение разработано таким образом, чтобы эта часть операции не содержала никаких данных C1 или C2. См. Шаг 2 на рисунке 5.

  3. Когда рентгеновский снимок и заключение рентгенолога готовы, его браузер перенаправляется в регламентируемую зону. Он загружает рентгеновский снимок и заключение, которые Web-приложение может преобразовать в XML-документ. Большой XML-документ состоит из данных C1, которые должны быть защищены.

    Данные C1 принимаются сервером Web-приложений DMZ и направляются в механизм шифрования, способный шифровать большие объемы неструктурированных данных. Создается симметричный ключ, который используется для шифрования содержимого документа. Симметричный ключ передается в EKMI, а зашифрованные рентгеновский снимок и отчет сохраняются в PBZ через безопасный Web-сервис. См. Шаг 3 на рисунке 5.

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

Операция RC3 в сфере промышленного производства

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

Операции этого типа состоят из следующих шагов.

  1. Инженер проходит аутентификацию на сервере в регламентируемой зоне и устанавливает сеанс связи. Затем он перенаправляется в PBZ. Запрос Web-сервиса надежно передает информацию сеанса из SECZ в PBZ.

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

    Поскольку операция состоит в изготовлении нового узла на заводе, ее открытая часть принимает неконфиденциальные составляющие ведомости материалов. См. Шаг 1 на рисунке 6.

    Рисунок 6. Операция RC3 в сфере промышленного производства
    Операция RC3 в сфере промышленного производства
  2. Браузер инженера перенаправляется в SECZ, где выполняется конфиденциальная часть операции. Это следующая информация:
    • чертеж изготавливаемого узла;
    • конфиденциальные составляющие BOM;
    • специальные инструкции по сборке узла, если таковые имеются;
    • любые другие конфиденциальные данные.

    Приложение разработано таким образом, чтобы в этой части операции необходимые данные C1 и C2 передавались для шифрования и маркировки в SECZ. Зашифрованный чертеж сохраняется в PBZ, так как он уже защищен. См. Шаг 2 на рисунке 6.

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


Заключение

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


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

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления, SOA и web-сервисы
ArticleID=845115
ArticleTitle=Создание Web-приложения, отвечающего требованиям безопасности данных
publish-date=11092012