Великі дані у хмарі - наскільки безпечні наші дані?

Автор: Roger Morrison
Дата Створення: 19 Вересень 2021
Дата Оновлення: 1 Липня 2024
Anonim
Александр Кардаков. Про стратегию развития и снижение кредитной нагрузки бизнеса | Big Money #31
Відеоролик: Александр Кардаков. Про стратегию развития и снижение кредитной нагрузки бизнеса | Big Money #31

Зміст


Джерело: Cuteimage / Dreamstime.com

Винос:

Дослідіть найбільші загрози для великих даних у хмарі та вивчіть способи захисту від них.

Обсяг великих даних дико збільшується з кожним днем. З 2500 екбабайтів у 2012 році очікується, що великі дані збільшаться до 40 000 екбабайтів у 2020 році. Отже, зберігання даних є серйозною проблемою, з якою може працювати лише хмарна інфраструктура. Хмара стала популярною опцією головним чином через її величезну ємність зберігання та умови використання, які не покладають на абонента жодних зобов'язань. Хмарне сховище може бути запропоноване у вигляді підписок і служб, що тривають заздалегідь визначений період. Після цього клієнт не зобов’язує його поновлювати.

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


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

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

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


Питання журналу даних та транзакцій

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

Проблеми перевірки даних

В організації великі дані можуть бути зібрані з різних джерел, включаючи пристрої кінцевих точок, такі як програмні програми та апаратні пристрої. Великим завданням є те, щоб зібрані дані не були зловмисними. Усі, хто має зловмисні наміри, можуть зламати пристрій, який надає дані, або програму, що збирає дані. Наприклад, хакер може здійснити атаку Sybil на систему, а потім використовувати підроблені ідентичності для надання шкідливих даних на центральний сервер колекції або систему. Ця загроза особливо застосовна у сценарії створення власного пристрою (BYOD), оскільки користувачі можуть використовувати свої персональні пристрої в межах корпоративної мережі.

Моніторинг безпеки даних у реальному часі

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

Ні помилок, ні стресу - покроковий посібник зі створення програмного забезпечення, що змінює життя, не руйнуючи ваше життя

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

Стратегії загрози безпеці обличчя

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

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

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

Сильна політика захисту даних

Необхідно вирішити загрози безпеці даних через суттєво слабкий захист даних у розподіленій системі та базі даних NoSQL.Паролі повинні бути хешовані або зашифровані захищеними алгоритмами хешування. Дані, що знаходяться в стані спокою, завжди повинні бути зашифровані та не залишатися відкритими, навіть після врахування впливу на продуктивність. Апаратне та масове шифрування файлів мають більш швидкий характер, що може значною мірою вирішувати проблеми щодо продуктивності, але зловмисники можуть також порушити шифрування апаратних пристроїв. Враховуючи ситуацію, є хорошою практикою використовувати SSL / TLS для встановлення зв’язків між клієнтом і сервером та для спілкування через вузли кластера. Крім того, архітектура NoSQL повинна дозволити підключаються сторонні модулі аутентифікації.

Аналіз

Аналітика великих даних може бути використана для моніторингу та виявлення підозрілих зв’язків із вузлами кластера та постійно шахти журнали для виявлення будь-яких потенційних загроз. Хоча екосистема Hadoop не має вбудованих механізмів захисту, інші інструменти можуть використовуватися для моніторингу та виявлення підозрілих дій, за умови, що ці інструменти відповідають певним стандартам. Наприклад, такі інструменти повинні відповідати вказівкам щодо проекту відкритої веб-програми безпеки (OWASP). Очікується, що моніторинг подій у реальному часі буде покращуватись із деякими подіями, які вже відбуваються. Наприклад, протокол автоматизації вмісту безпеки (SCAP) поступово застосовується до великих даних. Apache Kafka та Storm обіцяють бути хорошими інструментами моніторингу в реальному часі.

Виявляти людей, які не переживають людей, збираючи дані

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

Висновок

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