1. Традиційна архітектура Web-додатки
2. Малюнок 1. Стандартна архітектура Web-додатки
3. Малюнок 2. Переведення в платіжну систему
4. Поява хмари змінює підхід до інвестування
5. Задоволення нормативних вимог при хмарні обчислення
6. Малюнок 3. Модель архітектури Regulatory Compliant Cloud Computing
7. Класифікація даних для RC3
8. Транзакція електронної торгівлі RC3
9. Малюнок 4. Етапи транзакції електронної торгівлі RC3
10. RC3 транзакція в сфері охорони здоров'я
11. Малюнок 5. Етапи операції RC3 в сфері охорони здоров'я
12. Операція RC3 в сфері промислового виробництва
13. Малюнок 6. Операція RC3 в сфері промислового виробництва
14. Висновок
15. Ресурси для скачування

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

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

Існує багато підходів до вирішення цієї проблеми; ось полярні позиції:

• взагалі не використовувати хмара;
• повністю перейти на хмарні обчислення.

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

У цій статті я опишу, як архітектура Web-додатків певного типу оптимізує окупність інвестицій в ІТ з допомогою хмарних обчислень при дотриманні правил безпеки даних.

Традиційна архітектура Web-додатки

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

Малюнок 1. Стандартна архітектура 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

Далі ми розглянемо класифікацію даних в архітектурі 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

   
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 в сфері охорони здоров'я

   
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 в сфері промислового виробництва

   
2. Браузер інженера перенаправляється в SECZ, де виконується конфіденційна частина операції. Це наступна інформація:
   • креслення виготовляється вузла;
   • конфіденційні складові BOM;
   • спеціальні інструкції по збірці вузла, якщо такі є;
   • будь-які інші конфіденційні дані.

   Додаток розроблений таким чином, щоб в цій частині операції необхідні дані C1 і C2 передавалися для шифрування і маркування в SECZ. Зашифрований креслення зберігається в PBZ, так як він вже захищений. Див. Крок 2 на малюнку 6 .

   Всі зауваження з безпеки, які ставилися до попередніх операцій, відносяться і до цієї.

Висновок

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

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів