Позбавтеся від побоювань щодо безпеки даних в хмарі

1. Моделі хмарних обчислень
2. Малюнок 1. Моделі хмарних обчислень
3. Цілі клієнта в області безпеки
4. Таблиця 1. Цілі клієнта в області безпеки
5. Розмежування відповідальності за безпеку
6. Відповідальність постачальника хмарного сервісу
7. Малюнок 2. Області відповідальності постачальника хмарного сервісу в сфері безпеки.
8. відповідальність клієнта
9. dashDB: варіант застосування
10. системна архітектура
11. Малюнок 3. Системна архітектура dashDB
12. Використання dashDB
13. Вбудовані можливості забезпечення безпеки
14. Guardium Database Activity Monitoring
15. Визначені користувачем функції рішення Optim Data Masking
16. Принципи безпечної розробки
17. Висновок
18. Ресурси для скачування

dashDB: варіант застосування

Публічне хмарне рішення (public cloud) обіцяє безліч переваг підприємствам, які прагнуть підвищити свою конкурентоспроможність. Такі фактори, як скорочення витрат, еластичність і масштабованість, спонукають все більшу кількість підприємств звертатися до публічних хмарах. У недавньому звіті компанії Gartner прогнозується, що ринок сервісів на основі публічних хмари до 2017 року перевищить рівень 244 млрд. Дол.

До недавнього часу публічні хмари використовувалися здебільшого для менш відповідальних (т. Е. Не для критично важливих) функцій, таких як тестування і розробка. Незважаючи на кілька успішних випадків використання публічного хмари для реальних "виробничих" робочих навантажень (наприклад, використання хмарної платформи Amazon Web Services в компанії Netflix), більшість підприємств як і раніше побоюється довіряти третій стороні свої вразливі дані і відповідальні функції через побоювання про безпеку і нормативному відповідно.

Побоювання щодо безпеки та нормативного відповідності мають підстави. Однак ми встановили, що ці побоювання частково породжені недостатньою ясністю щодо безпеки в хмарі і відсутністю перевірених методик її забезпечення. Це не дивно, оскільки існують різні моделі хмарних обчислень, що розрізняються по покладеним на них очікуванням і по пропонованим до них вимогам. Крім того, не всі постачальники хмарних сервісів створені однаковими. Деякі постачальники спочатку приділяють увагу таким аспектам, як масштабованість, простота використання і доступність, і лише потім "прикручують" засоби безпеки. Інші постачальники, навпаки, починають зі вбудованих засобів забезпечення безпеки, які є для них стратегічним дифференцирующим ознакою.

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

• Моделі хмарних обчислень, пропоновані сучасними постачальниками хмарних сервісів.
• Безпека хмарної середовища
• Варіант застосування середовища dashDB

Моделі хмарних обчислень

Для розгляду безпеки в хмарі потрібно розуміння моделей хмарних обчислень, оскільки всі вони розрізняються по покладеним на них очікуванням і по пропонованим до них вимогам. У своїй спеціальній публікації за номером SP 800-145 Національний інститут стандартів і технологій США (US National Institute of Standards and Technology, NIST) визначає три моделі хмарних обчислень в такий спосіб.

SaaS (Software as a Service - програмне забезпечення як сервіс).

Споживач використовує додатки постачальника, яка крутиться в хмарної інфраструктурі. Доступ до цих додатків можливий за допомогою різних клієнтських пристроїв за допомогою інтерфейсу типу "тонкий клієнт", такого як веб-браузер (наприклад, електронна пошта на основі веб-додатки), або програмного інтерфейсу. Споживач не керує забезпечує хмарної інфраструктурою (яка включає в себе мережу, сервери, операційні системи, сховище або навіть окремі функції додатків) і не контролює її, за винятком можливості настройки в обмежених межах конфігурації програми під конкретні вимоги користувачів. Приклади SaaS-постачальників: Salesforce.com і Google. PaaS (Platform as a Service - платформа як сервіс) Споживач може розгорнути в хмарної інфраструктурі створені своїми силами або придбані додатки, створені з використанням мов програмування, бібліотек, сервісів і інструментів, що підтримуються Вашим постачальником даного хмарного сервісу. Споживач не управління забезпечує хмарної інфраструктурою (яка включає в себе мережу, сервери, операційні системи, сховище) і не контролює її, але має контроль над розгорнутими додатками і, можливо, над конфігураційними настройками середовища, що здійснює хостинг у відповідній програмі. Приклади PaaS-постачальників: IBM Bluemix ™ і Microsoft® Windows® Azure. IaaS (Infrastructure as a Service - інфраструктура як сервіс) Споживач має можливість ініціалізації основоположних комп'ютерних ресурсів (процесори, сховища, мережі і т. Д.) В тому місці, де ці ресурси можуть бути розгорнуті, і виконання довільного програмного забезпечення, до складу якого можуть входити операційні системи і додатки. Споживач не керує забезпечує хмарної інфраструктурою і не контролює її, але має контроль над операційними системами, сховищем, розгорнутими додатками і, можливо, обмежений контроль над деякими компонентами (наприклад, над брандмауерами хоста). Приклади IaaS-постачальників: IBM SoftLayer and Amazon Web Services (AWS).

На рис. 1 для кожної з трьох моделей хмарних обчислень показано, чим керує постачальник хмарного сервісу і чим керує клієнт.

Малюнок 1. Моделі хмарних обчислень

Прояснення ситуації з безпекою в хмарному середовищі

Ухвалення будь-який з перерахованих вище моделей хмарних обчислень супроводжується побоюваннями щодо безпеки, які можна розділити на наступні три категорії.

• Ідентифікація - охоплює ідентифікацію користувачів, управління доступом і повноваження.
• Захист - охоплює захист і доступність інфраструктури, даних і додатків.
• Розуміння - охоплює отримання відомостей про дії користувача, інтелектуальний аналіз загроз і забезпечення нормативного відповідності.

Цілі клієнта в області безпеки

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

Таблиця 1. Цілі клієнта в області безпеки

Модель хмарних обчислень Організація або покупець Основні цілі в області безпеки Приклад необхідних можливостей в області безпеки SaaS Вищий керівник (ІТ-директор, директор з маркетингу, директор з персоналу)

• Управління доступом користувача до SaaS-додатків
• Захист вразливих даних
• Повна наблюдаемость використання SaaS-середовища підприємством

• Федерірованія ідентифікаційних даних і єдиний вхід в систему
• Токенізація даних
• Моніторинг і звітність щодо відповідності нормативам

PaaS Групи по додатках і групи за напрямками діяльності

• Надання розробникам можливостей для конструювання безпечних хмарних додатків і сервісів
• Захист від загроз для додатків і для даних
• Повна наблюдаемость використання програми і сервісів даних

• API-інтерфейси аутентифікації і авторизації
• Шифрування бази даних
• Моніторинг і звітність щодо відповідності нормативам

IaaS ІТ-директор і ІТ-групи

• Захист хмарної інфраструктури з метою безпечного розгортання робочих навантажень і досягнення цілей щодо відповідності нормативам
• Наявність повної операційної спостережливості в масштабі всього хмарного розгортання і керівництво використанням

• Управління привілейованими користувачами
• Мережеві системи запобігання вторгнень і брандмауери
• Моніторинг і звітність щодо відповідності нормативам

Розмежування відповідальності за безпеку

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

Відповідальність постачальника хмарного сервісу

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

Малюнок 2. Області відповідальності постачальника хмарного сервісу в сфері безпеки.

Наступний рівень відповідальності - це засоби захисту мережі, до яких відносяться брандмауери та інші пристрої мережевої безпеки для моніторингу і контролю взаємодії на зовнішніх кордонах мережі і на стратегічних внутрішніх кордонах всередині мережі. Цей рівень призначений для захисту від традиційних загроз мережевої безпеки, таких як DDoS-атаки (Distributed Denial of Service), несанкціоноване сканування портів, перехоплення пакетів і IP-спуфінга. Мережева безпека також включає в себе захист передачі даних між організацією клієнта і постачальником хмарного сервісу. Приклади: вивантаження даних в сховищі об'єктів, таке як SWIFT в середовищі IBM SoftLayer або S3 (Simple Storage Service) в середовищі AWS. Для захисту від прослуховування і від зловмисних дій в цій ситуації зазвичай використовується технологія SSL (Secure Socket Layer).

Наступні рівні відповідальності залежать від моделі хмарних обчислень, прийнятої клієнтом. Наприклад, якщо клієнт прийняв модель IaaS, то область відповідальності постачальника хмарного сервісу обмежується рівнем гипервизора. Саме цю модель застосовують два провідних постачальника публічних хмар: SoftLayer і AWS. Якщо клієнт прийняв модель PaaS, то область відповідальності постачальника хмарного сервісу розширюються і на інші галузі безпеки, такі як ідентифікація і управління доступом, безпеку даних і управління уразливими. Якщо клієнт прийняв модель SaaS, то область відповідальності постачальника хмарного сервісу додатково розширюється і охоплює тестування веб-додатки на наявність вразливостей і усунення виявлених вразливостей.

Щоб спонукати клієнта до прийняття хмарних сервісу без будь-яких сумнівів, постачальник хмарного сервісу повинен пред'явити отримані ним сертифікати безпеки і представити аудиторські звіти, що підтверджують безпеку його хмарних сервісів. По суті, постачальник хмарного сервісу повинен продемонструвати, що хмарна ІТ-інфраструктура спроектована і управляється на основі перевірених методик і галузевих стандартів в області безпеки. Для постачальника найкращим способом підтвердити все це є проходження відповідної сертифікації, наприклад, згідно з такими стандартами: ISO 27001, Federal Information Security Management Act (FISMA), Federal Risk and Authorization Management Program (FedRamp), Payment Card Industry Data Security Standard (PCI DSS) , SOC, Cloud Security Alliance (CSA), Service Organization Control reports (SOC2, SOC3) і Safe Harbor. SoftLayer і AWS публікують свої матеріали з безпеки на сайтах SoftLayer Cloud Security і AWS Security Center відповідно.

відповідальність клієнта

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

Клієнту слід проаналізувати обов'язки з технічного контролю на предмет дотримання вимог з безпеки, конфіденційності та відповідності нормативам. Відповідальність клієнта починається там, де закінчується відповідальність постачальника хмарного сервісу. Крім того, вона залежить від застосовуваної моделі хмарного сервісу. Наприклад, якщо клієнт застосовує модель IaaS, то він несе повну відповідальність за всі артефакти, які він розгортає на ініціалізованої їм інфраструктурі. Ця відповідальність охоплює такі області, як управління доступом користувачів до робочих навантажень і до засобів системного адміністрування; захист робочих навантажень, така як "посилення" (підвищення ступеня захищеності) ОС, посилення бази даних, шифрування сховища, брандмауер хоста; а також моніторинг та звітність щодо відповідності нормативам. З іншого боку, якщо клієнт застосовує модель PaaS, то він зобов'язаний гарантувати безпеку створюваних ним додатків. Ця відповідальність охоплює такі області, як управління доступом користувачів до додатків, тестування безпеки додатків, шифрування даних; а також моніторинг та звітність щодо відповідності нормативам. Якщо клієнт застосовує модель SaaS, то його відповідальність охоплює такі області, як управління доступом користувачів до SaaS-додатком, токенізація даних, а також моніторинг та звітність щодо відповідності нормативам.

Щоб задовольнити вимоги до безпеки, конфіденційності та відповідності нормативам, клієнт може скористатися засобами технічного контролю, перенесеними ним в хмару, або задіяти відповідні сервіси з хмари. Наприклад, клієнт, який використовує модель IaaS, може за допомогою IP-таблиць посилити операційну систему Linux®, розгорнуту на ініціалізованої інфраструктурі, або задіяти рішення, пропоноване постачальником хмарного сервісу, наприклад, концепцію Security Groups в середовищі AWS. Точно так же клієнт може вдатися до такого способу, як розгортання власного віртуального пристрою, наприклад, Guardium® Database Activity Monitoring, з метою захисту баз даних, розгорнутих на ініціалізованої інфраструктурі. Ще один приклад - PaaS-клієнт, який використовує можливості сервісів сканування безпеки додатків із хмари для сканування додатків на предмет вразливостей в системі забезпечення безпеки.

dashDB: варіант застосування

dashDB - це середовище сховищ даних і аналізу, пропонована виключно в рамках хмарної інфраструктури. Спочатку вона доступна на хмарних платформах SoftLayer і AWS. dashDB являє собою всеосяжний стек програмного забезпечення, до складу якого входить операційна система Red Hat Linux, розгорнута на інфраструктурі постачальника хмарного сервісу.

Для ознайомлення з додатковою інформацією по цій темі скористайтеся посиланням: dashDB : Data Warehousing and Analytics for Everyone.

Наступний варіант застосування базується на моделі IaaS, в якій dashDB грає роль робочого навантаження, розгорнутої на інфраструктурі. Наприклад, на платформі AWS середу dashDB доступна як AMI-образ (Amazon Machine Image), що купується через Marketplace. Після придбання цієї пропозиції клієнтом AMI-образ використовується для інстанцірованія нової віртуальної машини. На платформі SoftLayer середу dashDB доступна як образ Flex Image; клієнт може вибрати між розгортанням на віртуальній машині і розгортанням на "голому залозі". Розгортання на голому залозі забезпечує додаткові переваги, в тому числі повну ізоляцію від інших орендарів і більш передбачувану продуктивність.

системна архітектура

На рис. 3 показана системна архітектура середовища dashDB, яка складається з таких компонентів.

• DB2® BLU - Система баз Даних IBM DB2 з функцією BLU Acceleration.
• Веб-консоль - консоль адміністрування для всієї системи.
• LDAP-сервер - вбудована система OpenLDAP для управління Користувачами и групами.
• Cognos®- програмне забезпечення IBM Cognos Business Intelligence (BI).
• Інструменти - набір завантажуваніх ІНСТРУМЕНТІВ, включаючі драйвери, InfoSphere® Data Architect (IDA), IBM Data Studio и Cognos Framework Manager (FM).
• Пакети для Сховище - Фізичні моделі Даних и типові Звіти для прискореного проектування сховище Даних. Пропонують следующие пакети: Customer Insight, Supply Chain и Market и Campaign.

Малюнок 3. Системна архітектура dashDB

Крім того, dashDB інтегрується з зовнішніми системами зберігання. Наприклад, в разі платформи AWS середу dashDB інтегрується з персистентного сховищем AWS EBS (Elastics Block Store). dashDB також інтегрується з AWS S3 (Simple Storage Service) з метою зберігання резервних образів бази даних. Точно так же на платформі SoftLayer середу BLU Acceleration for Cloud інтегрується зі сховищем об'єктів SWIFT.

Використання dashDB

Після ініціалізації dashDB за допомогою інтерфейсів ініціалізації, що надаються постачальником хмарного сервісу, клієнт використовує dashDB наступним чином.

1. Клієнт підключається до бази даних dashDB і створює схеми свого сховища.
2. Клієнт завантажує дані в свою базу даних dashDB. Ця процедура може бути реалізована кількома способами. Наприклад, клієнт спочатку переміщає дані в сховище об'єктів постачальника хмарного сервісу (такого як SoftLayer SWIFT або AWS S3), а потім переміщує ці дані зі сховища об'єктів в базу даних BLU Acceleration for Cloud. Забезпечує система баз даних DB2 була розширена таким чином, щоб дозволити клієнтам створювати резервні копії бази даних в сховищі S3 або SWIFT і завантажувати дані з S3 або SWIFT в базу даних DB2.
3. Клієнт підключає свої додатки до бази даних dashDB і починає дослідження точно так же, як при роботі з локальною базою даних. Крім того, клієнт може увійти в адміністративну консоль з метою додавання користувачів, призначення ролей або виконання інших завдань адміністрування.

Вбудовані можливості забезпечення безпеки

Нагадую, що описуваний варіант використання dashDB базується на моделі IaaS, тому клієнт несе відповідальність за захист розгортання dashDB на ініціалізованої інфраструктурі. Для цих цілей dashDB надає широкий набір вбудованих засобів безпеки, покликаний допомогти клієнту задовольнити вимоги з безпеки, конфіденційності та відповідності нормативам. Є такі вбудовані засоби безпеки.

Управління користувачами

Управління користувачами dashDB здійснюється у вбудованому LDAP-сервері. Внутрішні компоненти системи, такі як DB2, Cognos і веб-консоль, конфигурируются для виконання аутентифікації користувачів з використанням вбудованого LDAP-сервера. Крім того, для всіх цих компонентів підтримується технологія єдиного входу в систему (SSO). Управління користувачами виконується через інтерфейси веб-консолі. Контроль доступу на основі ролей Після створення користувача йому присвоюється конкретна роль, яка визначає його рівень доступу до системи: Administrator (адміністратор), Developer (розробник) або User (користувач). Контроль доступу на рівні рядків Дозволяє клієнту примусово застосовувати більш сувору політику безпеки, обмежуючи набір рядків, до яких користувач може звертатися в даній таблиці. Наприклад, якщо таблиця містить дані співробітника, то клієнт може легко налаштувати правило, що обмежує доступ співробітника до його власними даними або до співробітників, які повідомляють ці дані. Динамічне маскування даних Дозволяє клієнту примусово застосовувати більш сувору політику безпеки за допомогою обмеження доступу до чутливих стовпцями в даній таблиці. Наприклад, якщо таблиця містить стовпець Social Security Number (SSN - номер соціального страхування), то клієнт може легко налаштувати правило, згідно з яким при зверненні до цього одну з боку неавторизованого користувача йому буде повернуто замасковане значення замість реального значення SSN. Довірені контексти Дозволяють клієнтові додатково обмежувати користувача при здійсненні певних повноважень. Наприклад, клієнт може легко реалізувати правило, яке дозволяє підключення до бази даних тільки з певного IP-адреси. У разі трирівневих додатків довірені контексти дозволяють додатком середнього рівня перевіряти ідентифікаційні дані кінцевого користувача для доступу до бази даних (в інтересах контролю доступу та аудиту). Шифрування даних в стані спокою При ініціалізації системи dashDB клієнт може вказати, чи слід шифрувати базу даних. За замовчуванням база даних шифрується. При цьому застосовується технологія шифрування AES (Advanced Encryption Standard) в режимі CBC (Cipher Block Chaining) з 256-розрядним ключем. Управління шифруванням і ключами є повністю прозорим для додатків і схем.

Після ініціалізації клієнт може задати період зміни головного ключа. За замовчуванням цей період становить 90 днів, однак клієнт може вибрати інше значення. Зміна головного ключа здійснюється автоматично і прозоро. Резервні образи бази даних і табличного простору автоматично стискаються і шифрування. Резервні образи онлайнових даних також піддаються шифрування з використанням технології AES в режимі CBC з 256-розрядними ключами. Дані спочатку стискаються, а потім шифруються. Це особливо важливо, оскільки при зворотному порядку цих дій коефіцієнт стиснення буде незадовільним, так як шифрування за визначенням видаляє будь-які закономірності.

Підтримується застосування технології SSL для захисту трафіку бази даних і трафіку веб-консолі. Аудит Дозволяє клієнтам реалізувати політики моніторингу для підтримки підзвітності користувачів за свої дії і відстеження будь зловмисної діяльності.

Для надійного забезпечення безпеки і конфіденційності потрібен захист на кожному рівні стека. У цій сфері є такі вбудовані можливості.

dashDB використовує брандмауер хоста для захисту прослуховуючого сервісу від сканування портів і від інших загроз мережевої безпеки. По суті залишаються відкритими лише необхідні TCP-порти - для примірника DB2, для веб-консолі, для веб-консолі Cognos BI і для SSH (Secure Shell). На платформі AWS середу dashDB використовує концепцію AWS Security Groups для реалізації брандмауера хоста. На платформі SoftLayer середу dashDB використовує можливості IP-таблиць для реалізації брандмауера хоста. Посилення DB2 Після ініціалізації бази даних DB2 вона автоматично піддається посиленню. Так, для PUBLIC скасовуються повноваження CONNECT з доступу до бази даних, а також повноваження SELECT за вибором таблиць каталогу і уявлень. Конфігураційному параметру AUTHENTICATION диспетчера бази даних присвоюється значення SERVER_ENCRYPT, в результаті чого аутентифікаційні мандати користувачів ніколи не передаються між додатком користувача і сервером баз даних у вигляді відкритого тексту. При передачі по мережі ці мандати автоматично шифруються за технологією AES 256 незалежно від використання технології SSL. Обмежують інтерфейси веб-консолі Чи не є адміністраторами користувачі не мають можливості виклику адміністративних функцій, оскільки, згідно зі своїми принципами побудови, веб-консоль не вказує адміністративних функцій користувачам, які не належать до групи адміністраторів.

Guardium Database Activity Monitoring

Описані вище вбудовані можливості безпеки цілком достатні для багатьох клієнтів, однак для додаткового підвищення безпеки даних клієнт може додати і власне рішення. Наприклад, рішення Guardium Database Activity Monitoring дозволяє клієнту підвищити рівень безпеки. За допомогою Guardium клієнти здатні задовольнити навіть найсуворіші вимоги з безпеки, що наочно демонструє успішне застосування Guardium для захисту відповідальних баз даних на багатьох великих підприємствах в різних країнах світу. Деякі найважливіші можливості Guardium:

Розмежування обов'язків

Сервер Guardium може бути розгорнутий на окремому хості з окремим адміністратором, що забезпечує фізичне поділ обов'язків між адміністратором безпеки і адміністратором баз даних. Сервер Guardium може бути розгорнуто в хмарі або навіть, в разі необхідності, на майданчику клієнта. Моніторинг та генерація попереджень в реальному часі Рішення Guardium здійснює безперервний моніторинг всього вхідного і вихідного трафіку бази даних і в реальному часі виконує дії відповідно до політики безпеки. З точки зору обмеження вразливостей безпеки критично важливо миттєво виявляти вторгнення і випадки неналежного використання. Наприклад, надмірна кількість входів в систему може свідчити про те, що хтось намагається зламати базу даних методом грубої сили. Політика безпеки рішення Guardium підтримує правила трьох типів.

• Правила доступу - застосовуються до запиту клієнта до бази даних. Залежно від конкретного запиту можливі наступні дії: дозвіл проходження запиту, аудит, відправлення попередження, блокування запиту.
• Правила екструзії - застосовуються до відповіді бази даних на запит клієнта. Залежно від відповіді можливі наступні дії: дозвіл проходження відповіді, аудит, попередження, динамічне маскування вразливих полів у відповіді.
• Правила виключення - застосовуються в тому випадку, коли в базі даних відбувається виключення, наприклад, коли перевищено граничне кількість невдалих входів в систему. Як і для правил інших типів, рішення Guardium допускає високу гнучкість вибору дії в разі настання подібної події. Наприклад, адміністратору може бути відправлено по електронній пошті попередження з інформацією про відповідний подію.

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

Визначені користувачем функції рішення Optim Data Masking

Рішення Optim ™ Data Privacy допомагає багатьом організаціям переміщати дані з виробничого середовища в середу тестування без шкоди для безпеки даних і для задоволення розумних потреб додатків в осмислених тестових даних. Цей результат досягається за допомогою застосування алгоритмів контекстно-залежного маскування. Так, при маскуванні номера кредитної картки VISA масковане значення як і раніше виглядає як номер VISA, хоча насправді є фіктивним. Завдяки цьому додаток, що здійснює валідацію номерів кредитних карт, чи не порушує роботи середовища тестування.

Алгоритми рішення Optim Data Masking тепер доступні в вигляді UDF-функцій (user-defined function - обумовлена ​​користувачем функція). Наприклад, їх можна використовувати при отриманні даних з метою тестування в іншій базі даних. Оскільки ці алгоритми являють собою UDF-функції на SQL, їх можна використовувати в поєднанні з вбудованою можливістю динамічного маскування даних. Це дозволяє клієнту поєднувати переваги обох підходів для зміцнення безпеки, забезпечення прозорості додатків і застосування сучасної технології маскування.

Принципи безпечної розробки

Створення dashDB здійснювалася відповідно до найкращих методиками безпечної розробки, включеними в інфраструктуру IBM Secure Engineering Framework. Ці методики передбачають виконання оцінки ризиків і випуск документа з моделювання загроз. В процесі розробки для статичного і динамічного аналізу коду регулярно застосовуються інструменти IBM Security AppScan. Крім того, за допомогою інструменту Guardium Vulnerability Assessment перевіряється належне посилення бази даних dashDB.

Висновок

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

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

Дотримання викладених в цьому керівництві рекомендацій поряд з укладенням належного угоди про рівень сервісу (SLA) дозволить клієнтові досягти в хмарному середовищі такого ж рівня безпеки даних, який він здатний забезпечити на своєму майданчику - або навіть більш високого. Наприклад, провідні постачальники хмарних сервісів управляють своїми інфраструктурами з більш високим ступенем автоматизації, ніж це робиться на власних майданчиках більшості клієнтів. Автоматизація зводить до мінімуму ризик неправильного конфігурації в ручному режимі. Статистичні дані показують, що неправильне конфігурація є причиною більш ніж 60% проломів в системі захисту. Ще одним прикладом є готовність - базовий принцип безпеки. Організація малого розміру далеко не завжди здатна підтримувати кілька географічно розподілених майданчиків аварійного відновлення. Правильно обраний постачальник хмарного сервісу забезпечить такої організації більш широкі можливості для безперебійного функціонування бізнесу.

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

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

Схожі тими

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