Този сайт използва бисквитки (cookies). Ако желаете можете да научите повече тук. Разбрах

Новини ИТ сигурност

5 ключови факта за cloud-native сигурността

Все повече организации започват да изграждат своята сигурност и ИТ в облачното пространство. В тази връзка има пет ключови факта, които трябва да се вземат под внимание, по време на процеса.

от , 24 октомври 2017 0 666 прочитания,

5 ключови факта за cloud-native сигурността

Доскоро терминът „облак” заемаше основно място в дискусиите в технологичната индустрия, но вече той е изместен от понятието cloud-native или „родните“ за облачното пространство системи и от „родната“ за облака сигурност. Все повече организации започват да изграждат своята сигурност и ИТ в облачното пространство. В тази връзка има пет ключови факта, които трябва да се вземат под внимание, по време на процеса:

1. „Родната“ за облачното пространство сигурност няма нищо общо със системите за защитен достъп до облака

Прочетете още: Хибридните облачни архитектури – примерите на Amazon, Microsoft и Google

Когато служителите започнаха все повече да работят в облачното пространство, много организации осъзнаха, че трябва да използват софтуера като услуга. Поради промяната възникнаха притеснения за сигурността в публичния облак и така се сложи началото на епохата на системите (брокери) за защитен достъп до облака (CASB - Cloud Access Security Brokers).

Напоследък обаче повечето екипи за разработка на софтуер започнаха да създават облачен софтуер, тъй като техните компании се нуждаят от него, за да привличат потребители и да развиват новите бизнес модели. Това напомня за идеите: „всяка компания се превръща в софтуерна компания“ и „софтуерът изяжда света“.

Ако една фирма създаде приложение за своите клиенти, трябва да постави няколко слоя сигурност около него. Това е „родната“ за облачното пространство сигурност – и нейната роля е фундаментално различна от тази на CASB. Макар че и двете са свързани с облака, те се опитват да разрешат два много различни проблема.

2. „Родната“ за облака сигурност заменя съществуващите практики за активна защита от заплахи

Първият логичен избор за това как да се гарантира сигурността на „родния“ за облака софтуер, е използването на съществуващите инструменти за сигурност. Това е едната опция, но тя не е особено ефективна. Тя ще изисква да се автоматизират много практики или защитата от рискове ще се превърне в пречка за иновациите в компанията.

Следните няколко концепции за сигурността не се вписват в случая:

  • ИТ екип да проверява спецификите на всеки продуктов ъпдейт и да валидира неговото съответствие.

  • Сегментиране на мрежата – макар на теория това да е добра концепция, тя не работи на практика. Служителите бързо започват да намират причини защо им трябва достъп между различните части и след като дисциплината не може да се спазва, то следователно сегментацията не функционира.

  • Ролята на WAFs – синхронизирането между WAFs има за цел да спира атаките между работните задачи, но отговорният за това служител не може да следи всички микро работни задачи на фона на другите протичащи промени.

„Родната” за облачното пространство сигурност има повече информация за приложенията и я използва, за да автоматизира всички споменати елементи. Автоматизирането позволява компанията да получи по-голяма сигурност. Освен това позволява фокусът да не се поставя върху ръчното променяне на механизмите за защита всеки път, когато има ъпдейт.

3. „Родната” за облака сигурност се нуждае от няколко слоя защита

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

„Родната” за облака сигурност се нуждае от няколко слоя защита

4."Родната” за облачното пространство сигурност трябва да бъде комплексна

Движението на DevOps променя обичайното групирането на служителите. От едната страна са разработчиците, които искат да предоставят микроуслуги, а от друга страна е екипът по инфраструктурата, който се занимава с облачното пространство. Често дори тези две страни се превръщат в един “облачен” екип с много отговорности. В тази връзка изглежда логично да се създадат две групи, гарантиращи сигурността съответно в:

1. “родната” за облака инфраструктура

2. “родните” за облачните системи приложения

Това ще промени възможностите за сигурност, предлагани на пазара. Доставчиците на облачни услуги ще добавят по-традиционни инфраструктурни предложения за облачното пространство, увеличавайки привлекателността на своите платформи и осигурявайки цялостни оферти, които ще покриват всички изисквания за сигурност на инфраструктурата. От друга страна, доставчиците на сигурност също ще трябва да предоставят комплексни решения за безопасност.

5. „Родната” за облака сигурност се поддържа от екип за облачното пространство

Обикновено слоевете на сигурност, споменати в предишната точна, изискват намесата на различни служители или екипи (например сървър, мрежа, сторидж, софтуерно разработване). Една компания може да има хора, които ръчно да добавят тези слоеве защита, когато инфраструктурата се премества. След това трябва да се включат правилните оперативни експерти, за да извършат необходимите настройки в облачното пространсто. Но преместването на тези ресурси трябва да бъде незабавно и възможностите за гарантиране на сигурността трябва да се подобрят.

„Родната“ за облачното пространство сигурност вече постави началото на голямата промяна. Тя налага архитектите на сигурността и инфраструктурата да определят слоевете за сигурност – но ежедневно механизмите за сигурност, които ги активират, трябва автоматично да се свързват към облака и DevOps процесите. Това завършва целия процес, като позволява на DevOps и екипите за облачното пространство да работят възможно най-безпрепятствено.

КОМЕНТАРИ ОТ  

Полезни страници
    За нас | Аудитория | Реклама | Контакти | Общи условия |
    Действителни собственици на настоящото издание са Иво Георгиев Прокопиев и Теодор Иванов Захов