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

Ќовини »“ сигурност
бр. 5, 2013

ƒинамика на сигурността Ц какво следва от адаптаци€та на » “ инфраструктурата към облачен компютинг

ѕриемането на нови технологии в организациите е свързано с предварителна оценка на рисковете, положителните и отрицателните страни на планираната пром€на (SWOT анализ и управление на пром€ната). ѕредлагаме на вашето внимание част от промените, които настъпват в сигурността на системата от » “ на организаци€та вследствие на преминаването към услуги от облака

от , 22 май 2013 1 6008 прочитани€,

“радиционно, »“ обкръжението се разполага зад защитната стена на организаци€та и всички сървери, виртуализарани или не, са профилирани в услуга на специфичен вид бизнес. ќрганът, които поддържа системата за сигурост на това обкръжение има възможност да подбира компонентите за защита измежду множество наложени и утвърдени продукти – защитни стени, антивирусни системи, сървъри за журнализаци€, управление на ъпдейтите, прокси сървъри и други. “ова дава възможност да се постигне висока степен на контрол върху сигурността на »“ средата и да се покри€т изисквани€та на различни стандарти за сигурност.

ѕри облачната инфраструктура сървърите са виртуализирани и са поделени между различни организации с различни видове бизнес. ¬ случай, че се наложи екипът на една организаци€ да обедини ресурси от публичен облак, който се намира в —ингапур например, с частни€т и облак намиращ се в јнгли€ то той не може да използва утвърдени, зрели, наложени на пазара продукти за да конструира сигурността на това свързване. “ова намал€ва доверието в сигурността при облачното обкръжение [3].

Ќапример

Ќека организаци€та, ко€то разглеждаме има изградена защита на системата си от » “ и т€ включва развити подсистеми за:

- прилагане на ъпдейти към всички операционни системи, приложени€, мрежови устройства, принтери, дори UPS-и;

- управление на активите, като води на отчет всички платформи с подробности за хардуера, инсталирани€ софтуер и ютилизаци€та му.

— по€вата на облачни€ компютинг изисквани€та към функциите на горните подсистеми се промен€т. ¬ този случай архитектурата е основана на два или повече отдалечени дейта центъра и хипервайзори с виртуални машини в т€х. ¬иртуалните машини могат да бъдат активни, спрени или в състо€ние на снапшот.

ѕодсистемата за ъпдейти тр€бва да отчита всички виртуални машини от всички дейта центрове на доставчика и да въздейства върху т€х, тъй като при преместването на една виртуална машина от един дейта център в друг т€ може да бъде пропусната и да остане без ъпдейти. ѕроцесът на обнов€ване тр€бва да е свързан с подсистемата за управление на активите, тъй като при поредното налагане на ъпдейти ще бъдат пропуснати всички спрени машини и тези в състо€ние снапшот.

—читам, че подсистемата за управление на активите, комбинирана с фукци€ за мониторинг на динамиката на виртуалните машини и във вид съобразен с облачната инфраструктура, може да бъде втори€т стълб след ъпдейтите, на който да се основе ц€лостна схема за управление на сигурността на виртуалните машини.

¬ таблица 1 са представени основните процеси, които вод€т до нови изсквани€ към налагането на ъпдейтите и мониторинг на сигурността на виртуалните машини в динамиката, характерна за жизнени€т им цикъл в средата на облачни€ компютинг.

ќтражението на еластичността

 лючова разлика между облачни€ компютинг и конвенционалните дейта центрове е еластичността. “€ по същество е характерна черта за виртуализаци€та. —ървърите вече са във вид на файлове и изпълними задачи и могат да бъдат подлагани на различни операции – копиране, преместване, преоразмер€ване на елементите оперативна памет, дисково пространство, брой мрежови контролери, поддържане на снапшоти, резервиране на шаблони с цел последващо архивиране.

≈ластичността дава възможност на организациите да “ро€т” сървърите: бро€т им лесно се увеличава заедно с това и наличната мощност за компютинг. “ова увеличава рисковете от компрометиране тъй като:

- при копиране на сървър се дублират и неоткритите и експонираните му у€звимости;

- с копирането на сървърите драматично и за минути се увеличава общата повърхност за атаки на дейта центъра.

Ќеактивните образи на сървърите както и снапшотите са виртуални машини, които са записани във файлове и са предназначени за последващо реактивиране или служат за шаблони за нови сървъри. “ова удобство се заплаща с цената на сигурността: тъй като тези машини не са активни когато се инсталират поправки по сигурността, те остават незащитени от новооткритите у€звимости, без промените в конфигурациите при изменени€ в политиките, както и не се отраз€ва см€ната на правата за достъп на потребителите [6].

≈дин неправилно конфигуриран сървър може да бъде мултиплициран при клониране на нови сървъри и да се превърне в огнище на зараза ц€лата сървърна ферма на доставчика.

≈ластичността влече проблеми по сигурността, които не съществуват в традиционните дейта центрове. ѕо€в€ва се необходимост от функции за мониторинг на сигурността, който включват:

  • јјј контроли, които да контролират кой може да иска допълнителни ресурси от пуловете с поделени ресурси или да освобождава заети ресурси;

  • ќсъществ€ване на мониторинг и одит на за€вките за получаване и освобождаване на ресурси за да се гарантира, че квотите са спазени и услугите остават налични;

  • ќсигур€ване на гарантирано заличаване на остатъчните данни от всички компоненти от пула с освободени, консумирани от наемател€, ресурси .

ќт гледна точка на наемател€ е необходимо да има усещане за безкраен капацитет на ресурсите. ќт гледна точка на доставчика на облачни услуги той е собственик на пул с фиксирани размери, който съдържа поделените между наемателите ресурси и тр€бва да се управл€ва така, че да са изпълнени услови€та за качество на услугата [8].

√отовите виртуални машини

¬ последните години всички производители на устройства за защита – защитни стени – IDS/IPS, UTM, антиспам устройства, антивирусни устройства започнаха за предлагат готови виртуални машини [1] за тестване на продуктите си и за реално приложение в среди за виртуализаци€. ќтделно съществуват множество малки и големи производители на готови виртуални машини, които могат да се копират от »нтернет и да се приложат директно в среди за виртуализаци€.

√олемите производители предлагат инструменти за подготовка на собствени виртуални машини [1], и виртуализаци€ на съществуващи производствени платформи върху реален хардуер, които се прехвърл€т в среда на хипервайзор поради най-различни причини, например тенденци€ за нарастващи хардуерни проблеми [7]. ѕроизводството на виртуални машини с готови инсталирани приложени€ и предлагането им на пазара носи заплахи [4], които по наше мнение в повечето случаи са аналогични на заплахите от неконтролирано копиране на софтуер от сайтове в »нтернет и инсталирането му в служебните компютри.

√отовите виртуални машини с по€вата си б€ха предназначени за традиционните дейта центрове със сървъри за виртуализаци€, но днес фокусът на приложението им се измества в облачни€ компютинг [2],[3]. ƒо какви последстви€ може да доведе това?

¬ средата на доставчика на облачни услуги може да попадне машина, ко€то е компрометирана или такава, ко€то е подготвена и съдържа инструменти за изпълнение на атаки от най-различен тип. ѕубликации по този въпрос споменават възможности за имплементиране на инструменти за bot-net, DLP, DdoS, кражба на криптиращи ключове [4]

 акъв може да бъде подхода към тази заплаха? Ќапример използване приложени€ за откриване на вируси върху образи на виртуални машини, които са офлайн или тестване в изолирана среда.

“ук е м€стото да си представим колко полезна може да бъде системата за управление на активите, ко€то може да води и то в динамика отчета на всички виртуални машини с заедно с приложени€та върху т€х и дори лицензите им. Ќезависимо, за колко време са съществували.

—ъжителството на много наематели в една облачна среда е друг аспект на сигурността на виртуалните машини. —ъвместно битуване на виртуални машини, които са собственост на различни наематели, в една облачна среда, крие набор от опасности, на които ще се спрем в следваща стати€.

¬ели€н ƒимитров е професионалист с богат опит в областта на информационната сигурност. –аботил е като преподавател във ¬оенна академи€ «√. —. –аковски» до 1993 г. ”частвал е в проекта за цифровизаци€та на —тационарната  »— на Ѕј като експерт. Ѕил е архитект и проектант на ј—” в Ѕългарската арми€ (Ќационален ¬оенен  оманден ÷ентър, ј—” “—транджа”). ”частвал е в изграждането на елементи от информационната сигурност в ѕрезидентство на –Ѕ, ЅЌЅ, Ќ—», ћинистерство на «дравеопазването, ¬оенномедицинска академи€, Ѕърза помощ, ”правление ћитници, ќбщинска банка и други организации. Ќаучните му интереси в последните години са насочени към информационната сигурност при облачни€ компютинг.

[1] Build a virtual appliance. How to Build a Virtual Appliance, http://www.vmware.com/appliances/getting-started/build/how/:Accesed 18.09.2012, 2012.

[2] BitNami Carlos. How to start a bitnami machine image (ami)? http://wiki.bitnami.org/cloud/How_to_start_a_BitNami_Machine_Image_(AMI)%3f, December 2011.

[3] Intel IT center. What’s holding back the cloud? In Intel Survey on Increasing IT Professionals Confidence in Cloud Security. Intel Corporation., May 2012.

[4] Claudia Eckert. Cloud computing new challenges for it security. In Fraunhofer Institute for Secure Information Technology (SIT), February 2010.

[5] RAPID7 Corporate Headquarters. The dynamic nature of virtualization security. In The need for real-time vulnerability management and risk assessment, 2012.

[6] Inteligence and National Security Aliance. Risks and benefits of cloud computing for the intelligence community. http://insaonline.com/assets/files/Press%20Releases/RisksAndBenefitsofCloudComputingfortheIC.pdf, March 2012.

[7] Transworld Data Research. Transworld data case study. In Building Workload Images for IBM System z with SUSE Studio, 2012.

[8] Deb Shinder. http://www.windowsecurity.com/articles/security-considerations-cloud-computing-part5.html. Security Considerations for Cloud Computing (Part 5) - Rapid Elasticity, June 2012.

 ќћ≈Ќ“ј–» ќ“  

ѕолезни страници
    «а нас | јудитори€ | –еклама |  онтакти | ќбщи услови€ | ƒеклараци€ за поверителност | ѕолитика за бисквитки |
    ƒействителни собственици на насто€щото издание са »во √еоргиев ѕрокопиев и “еодор »ванов «ахов