Головна » 2013 » Жовтень » 1 » Обман чи непорозуміння?
19.17.20

Обман чи непорозуміння?

Обман чи непорозуміння?
Нещодавно мені довелося виступати на конференції , повністю присвяченій хмарам , - стартапи і вже існуючі не один рік компанії навперебій заманювали в свої тенета довірливих ІТ -директорів та ІТ -менеджерів. «У нас найкраще співвідношення ціни та якості! » « У нас є ЦОД не тільки в Росії , але і в Європі! » « Наша платформа розміщена в США на самих надійних серверах Amazon ! » «Наші хмари повністю захищені ! » « Ми відповідаємо ФЗ -152 »! І так далі, і тому подібне ...

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

Відразу хочу відзначити , що представлений у статті чек -лист з питаннями , які варто задавати хмарному провайдеру , досить об'ємний і враховує практично всі основні напрями забезпечення безпеки. Це результат довгої роботи нашої компанії з різними хмарними провайдерами. Але далеко не всі з описаних в чек -листі вимог потрібні клієнтам . Це класична дилема : що важливіше , безпека чи зручність? А якщо безпека , то яка потрібна нам - для роботи або для галочки (для виконання не завжди адекватних вимог законодавства ) ? І звичайно , не варто забувати , що передаючи дані або програми в хмари , ми не знімаємо з себе відповідальності за захист на клієнтській стороні. Відомий такий парадокс: конфіденційності в хмарах вимагають майже всі (особливо після історії зі Сноуденом ) , а от про те , чи безпечний канал, що з'єднує клієнта і хмарного провайдера , чомусь забувають. Понад 80 % компаній , « пішли» в хмари , ніяк не захищають інформацію , що відправляється через провайдера , - трафік передається у відкритому вигляді. Як можна вимагати безпеки від провайдера , якщо ми не можемо самі її забезпечити ? Але повернемося до вибору хмарного провайдера з точки зору безпеки.

Почніть з головного

Економія і можливість зосередитися на основних компетенціях - основний мотив переходу до хмар. Але очевидно , що приймаючи таке рішення , необхідно зважити всі ризики - стратегічні , юридичні , операційні , фінансові ... Чи готові ми віддати « чужому дядькові » свої дані і додатки ? Чи не відповівши позитивно на це питання , переходити до решти нерозумно . А відповівши , ви повинні будете задати собі основне питання : чого побоюватися при переході в хмари ? Втрати даних? Крадіжки додатків? Модифікації даних? Доступу до даних спецслужб та інших третіх осіб? Неможливості «достукатися» до хмарного провайдера ? Масок -шоу на стороні постачальника послуг і « виїмки » ваших даних? Переходу прав на ваші програми до провайдера ? Загроз багато і сформувати їх модель можете тільки ви - жоден хмарний провайдер вам тут не допоможе. Це ваші ризики і ваші погрози - постачальник послуг може тільки допомогти їх нейтралізувати або відмовитися від боротьби з ними , якщо для нього витрати будуть великі.
Сформувавши модель загроз , ви можете переходити до складання списку вимог щодо захисту. І ось тут вам допоможе чек -лист , до складу якого ми й переходимо .

Чек -лист

Перелік запитань , відповіді на які ви повинні отримати від хмарного провайдера , виглядає наступним чином :
Захист даних та забезпечення privacy
управління уразливими
управління identity
Об'єктова охорона і персонал
Доступність і продуктивність
Безпека додатків
управління інцидентами
Безперервність бізнесу та відновлення після катастроф
Ведення журналів реєстрації ( eDiscovery )
Сompliance
фінансові гарантії
завершення контракту
Інтелектуальна власність
Захист даних - питання № 1

Коли ми говоримо про безпеку хмар , то, очевидно , перше , що нас цікавить , - як будуть захищені дані, передані в цю хмару . І тут саме час поставити такі питання , відповіді на які допоможуть вам краще зорієнтуватися при виникають ризики і складнощі :
Які дані я готовий передати в хмару ?
Для відповіді на це питання у вас повинна бути проведена класифікація даних з їх пріоритезацією за різними критеріями - важливість , конфіденційність , частота використання , швидкість доступу , віднесення до тієї чи іншої таємниці і т. п. Від такої класифікації залежить , що ви зможете віддати в хмара , а що повинні обробляти самостійно.
Як мої дані відокремлені від даних інших клієнтів?
Де зберігаються мої дані ? Неважливий з технічний точки зору питання стає дуже актуальним у контексті виконання вимог законодавства про персональні дані . Згідно з Федеральним законом № 152- ФЗ « Про персональних даних» транскордонна передача даних ( тобто за межі Російської Федерації ) вимагає від оператора персональних даних письмової згоди на це з боку суб'єкта , чиї дані будуть передані за кордон. Якщо хмара розташовується тільки в Росії , то подібна проблема відсутня , а якщо ні , то вам необхідно отримати згоду всіх суб'єктів персональних даних. Саме вам , а не хмарному провайдеру . І те , що він підносить як свою перевагу , для вас перетворюється на нічний кошмар , так як отримати письмову згоду від людини, яка жодного разу не чув про ФЗ -152 , непросто.
Як забезпечується конфіденційність і цілісність моїх даних?
Як здійснюється контроль доступу до моїх даних ?
Як дані захищені при передачі від мене до хмарного провайдеру ?
Це ще один головний біль - причому як з технічної , так і з організаційної точки зору. Згідно ряду нормативних актів конфіденційність інформації повинна забезпечуватися за допомогою сертифікованих в ФСБ шифрувальних засобів. Чи можна очікувати , що на майданчику Amazon або Azure такі кошти є? Навряд чи . У випадку з використанням IaaS - моделі такі кошти можна встановити в орендованій інфраструктурі самостійно , а от у SaaS і PaaS - майже нереально. Але навіть якщо ви і самостійно встановіть засоби шифрування на віддаленій майданчику , то виникне питання про їх експорті за межі РФ , а це дуже і дуже нетривіальне завдання , оскільки потрібно отримати купу погоджень від різних відомств.
Як дані захищені при передачі від одного майданчика хмарного провайдера до іншого ?
Реалізовано чи заходи з контролю витоків даних ?
Чи може третя сторона отримати доступ до моїх даних ? Хто, як і за яких умов?
Чи всі мої дані видаляються по завершенні надання сервісу ?
Стій ! Хто йде ?

Управління ідентифікаційними даними користувачів - непросте завдання в корпоративній мережі , і для її вирішення застосовуються різні технології і продукти. А тепер задайте собі питання: як автентифіковані мої користувачі при доступі до чужої інфраструктурі? Чи можна інтегрувати каталог облікових записів хмарного провайдера з моїм ? Якщо ні , хто буде переносити дані з мого каталогу в хмарний ? А хто буде керувати чужим каталогом ? А захищати? Бачите , як багато питань виникає при вирішенні всього однієї задачі ? І адже чим більше систем ви переносите в хмару , тим більше непростим виявиться рішення задачі . Можливо , варто задуматися про федеративної системі ідентифікації і аутентифікації ...

Безпека додатків

Дані, що передаються в хмари , знаходяться там не самі по собі (якщо це , звичайно, не файлове сховище) . Вони обробляються різними додатками - ERP , CRM , SCM , HRM і т. п. Низька захищеність таких додатків , особливо самописних , - дуже поширена проблема . Тому варто задати хмарному провайдеру наступні питання :
Чи виконуються рекомендації OWASP при розробці додатків? Чим це можна підтвердити ?
Проходило чи додаток зовнішню сертифікацію і тестування? По ряду нормативних актів це або вже є (наприклад , в PA DSS або при захисті персональних даних ), або може стати ( при захисті банківської таємниці) обов'язковою нормою .
При наданні хмарних послуг чи існують програми третіх фірм? Які ?
Які захисні заходи додатків застосовуються? Web Application Firewall ? Database Firewall ? Сканери захищеності додатків? Аудит БД ?
управління уразливими

Якою б досконалою не була система захисту на початку експлуатації , з часом ступінь її надійності зменшується. Некоректні налаштування , вразливі оновлення, знайдені нові діри ... Причин багато , а результат один - зниження рівня безпеки. Контролювати його можна і потрібно , але як це завдання вирішує (і чи вирішує ) хмарний провайдер ? Як часто сканується інфраструктура на предмет її захищеності ? Ким і за допомогою чого виконується сканування ? Чи може замовник проводити зовнішнє сканування «свого» хмари ? На яких умовах? Яка процедура усунення вразливостей і установки патчів ?

управління інцидентами

Ще одна особливість виникає , коли відбувається інцидент безпеки. Хто і як повинен реагувати на нього ? За наявності різних відповідальних за інфраструктуру , за програми і дані питання зовсім не пусте. Ситуація ще більше ускладнюється , якщо хмарний провайдер знаходиться за кордоном , в іншому часовому поясі і спілкуватися з ним доводиться на його рідній мові . Це явно не сприяє оперативності реагування на інциденти безпеки.
Якщо ваша політика реагування на інциденти увазі не просто усунення наслідків та недопущення повтору інцидентів , але і взаємодія з правоохоронними органами , то слід уточнити відповіді на такі питання :
Як хмарний провайдер забезпечує збір доказів несанкціонованої діяльності? Як довго хмарний провайдер зберігає журнали реєстрації і чи можливо збільшення цього терміну?
Чи можна організувати зберігання логів в зовнішньому сховищі ? Як ?
Чи надаються журнали реєстрації замовнику ? У якому форматі і якою мовою ?
Інтелектуальна власність

Інше питання , який взагалі незрозуміло до чиєї компетенції належить , теж дуже важливий. Йдеться про права на інформаційні ресурси та інтелектуальну власність . Кому належать права на інформацію , передану хмарному провайдеру ? А на резервні копії? А на Реплікованих дані ? А на журнали реєстрації ? А на додатки ?

Аналогічна ситуація з правами на інтелектуальну власність . Які види інтелектуальної власності ви плануєте передавати в хмару :
Додатки ( програми для ЕОМ) та бази даних
Телевізійне мовлення ( IPTV )
Секрети виробництва ( ноу -хау)
Промислова власність (винаходи тощо)
Засоби індивідуалізації (товарні знаки і т. п. )
Завдання не тільки в складанні переліку таких відомостей , а й у її оцінці та введення режиму комерційної таємниці . І тут нас підстерігає ще одна складність . Якщо режим захисту комерційної таємниці складно встановити у себе на підприємстві (а це дійсно непросто) , то як це зробити на чужому підприємстві? А якщо він не введений , то говорити про захист прав взагалі не має сенсу - жоден суд не прийме позов в подібній ситуації.

завершення контракту

Завершення контракту - ще одна тема , про яку мало хто думає в процесі укладення хмарного договору . Що ви будете робити , якщо вирішите не продовжувати контракт з хмарним провайдером ? А що буде з вашими даними і додатками ? І це тільки перша порція питань. До інших відносяться:
Яка процедура повернення даних і додатків? У якому форматі ? Строки повернення ?
Як переконатися , що дані знищені , а ваші програми не будуть використовуватися іншими? У який момент вони будуть знищені ? Які гарантії ?
Контроль над усе

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

Законодавство

Відповідність законодавчим вимогам , мабуть , найболючіша тема, що стосується хмарних обчислень . Пов'язано це з тим , що чинне законодавство як у сфері інформаційної безпеки , так і в інших галузях регулювання , наприклад , персональних даних , створювалося , коли хмар ще не було і не могло враховувати появу подібних послуг. Тому досить забавно чути або бачити заяви хмарних провайдерів про те , що вони « повністю відповідають ФЗ -152 ». Якщо буквально слідувати всім підзаконним актам , то хмарний провайдер повинен мати ліцензії ФСТЕК і ФСБ на діяльність у галузі захисту інформації та шифрування , використовувати сертифіковані засоби захисту , атестувати свої інформаційні системи (при роботі з держорганами ) , мати в штаті не менше трьох фахівців з вищою освітою в області інформаційної безпеки , і т. д. і т. п. Я не знаю в Росії хмарних провайдерів , які могли б похвалитися таким багатством.

Я не готовий вдаватися в тонкощі нормативного регулювання хмар ; тільки окреслю основні моменти , на які слід звернути увагу при виборі хмарного провайдера і укладення договору з ним :
Обов'язок захищати конфіденційну інформацію ( в російському законодавстві існує 65 видів таємниць , що вимагають захисту) .
Захист прав суб'єктів персональних даних і самих персональних даних.
Захист державних інформаційних ресурсів, у тому числі і при передачі їх в хмари .
Захист банківської таємниці та інших відомостей обмеженого доступу , оброблюваних банками та іншими учасниками Національної платіжної системи.
Забезпечення СОРМ .
Збір та зберігання даних для судових розглядів ( eDiscovery ) .
Юрисдикція і відповідальність.
висновок

Беручись за написання цієї статті , я не ставив перед собою завдання ускладнити розвиток ринку хмарних обчислень в Росії. Просто , переходячи до них , треба усвідомлювати , що таке безпека хмарної інфраструктури , що вам може і що має пропонувати хмарний провайдер і як проконтролювати , що він вас не обманює. Їли ви зважуєте всі плюси і мінуси , то перехід до хмар може дійсно дати ті переваги , про які там багато і наполегливо віщають різні аналітики і продавці хмарних послуг.
Категорія: Історія України | Переглядів: 1203 | Додав: pqpq | Рейтинг: 0.0/0
Всього коментарів: 0
avatar