Програма за насърчаване на малките и средните предприятия


Концепцията за периметър при IaaS става неприложима



страница19/19
Дата25.08.2016
Размер1.47 Mb.
#7187
ТипПрограма
1   ...   11   12   13   14   15   16   17   18   19

6.3Концепцията за периметър при IaaS става неприложима


Организациите са фокусирани върху външния периметър и често не обръщат внимание на софтуера във вътрешността на мрежата. Инстлират защитни стени и прокси сървъри, средства за мрежово откриване/предотвратяване на проникване (IPS/IDS) и т.н., за да укрепят периметъра. Същевременно вътре в локалната им мрежа сигурността може да се свежда до антивирусен софтуер и евентуално някои ограничения на правата. Крайният резултат е, че системата става лесна плячка за външен нападател, който успее веднъж да проникне през периметъра [20].

Интересен пример е DMZ, в която сървърите, достъпни откъм Интернет са изолирани в отклонение на защитната стена. Ако един от тях бъде атакуван успешно то компроментирането на останалите е лесна задача. Веднъж проникнал през периметъра, зломишленикът получава лесен достъп до останалите сървъри 22.

Бил Чесуик е съавтор на "библията за защитните стени" (Cheswick, Bellovin and Rubin "Firewalls and Internet Security: Repelling the Wily Hacker", 1994), претърпяла две издания. През 2008 г. на конференция в Сан Франциско в интервю, взето от Хърбърт Томпсън той изненадващо казва "не съм ползвал защитна стена повече от 10 години" и "те си имат тяхното място и аз наистина искам моите хостове да са сигурни, но те не се нуждаят от защитна стена"23.

Ако регулярно пачвате и конфигурирате системите те могат да се експонират в Интернет без традиционните защитни стени от периметъра и в добавка ще имате чист канал към Интернет, което компенсира допълнителните рискове и усилията по пачването и конфигурирането [24].

При облачния компютинг, особенно при модела за услуга IaaS концепцията за периметър е мъртва. Може да се постави виртуална машина със защитна стена пред сървърите в облака, но Layer 2 е също виртуализиран което води до възможности за заобикаляне на сигурността на Layer 3 на защитната стена. Това до голяма степен принуждава организациите да се откажат от периметъра и да се фокусират върху защитата на реалните активи със стойност за тях.

Например в защитните стени на всички уеб сървъри от IaaS се конфигурират ограничения за обмен по HTTP и HTTPS единствено с хостовете, които балансират натоварването им. В предишните времена всеки сървър би приел и други заявки до тези портове.


6.4Периметърът на доверените лица


С периметровия модел ние казваме "вярваме на вътрешните системи повече отколкото на външните" и прилагаме съответни контроли по сигурността. Облачния компютинг ни принуждава да преосмислим тази демаркационна линия и да я преместим обратно във всеки сървър. С което визията за сигурност добива вида "доверяваме се на останалите системи само колкото е необходимо", независимо дали те са вътрешни или външни [20].

От това положение следва, че организациите вече управляват защитна стена във всеки от сървърите си, а не една единствена както досега при периметъра. Когато сървърите се местят или клонират сигурността им трябва да се адаптира адекватно. Например в облачното обкръжение се променя често IP адреса на виртуалната машина. От примера виждаме, че при смяна на IP адрес на някой от хостовете за балансиране на натоварването, защитните стени на уеб сървърите трябва да установят това и да променят съответните правила в хостовете. Затова на твърдението, че облачният компютинг не е сигурен може да се отговори: облачният компютинг ни кара да сме много по-прецизни в начина, по който прилагаме сигурността [23].

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

При формиране на рейтинга следва да се разгледат следните критерии:



  • Икономически:

  • кредитен рейтинг на компанията провайдър на услугата;

  • цена на услугата;

  • Правни:

  • законодателство в страната домакин и/или общност домакин (ЕС, САЩ, РФ и др.);

  • Политически:

  • политическа стабилност в страната /общността домакин;

  • Технологични:

  • интерфейс на услугата;

  • поддръжка ориентирана към клиента;

  • възможност за ползване от мобилно устройство и различни ОС;

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

  • достъпност.

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

6.5Примери за пробиви в сигурността на данните при използване на облачни технологии


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

  • служители на организацията;

  • служителите на доставчика на услугата;

  • допуснатите до информационните ресурси на организацията външни служители на партньори и контрагенти;

  • крайните потребители, допуснати за работа и принадлежащи към останалите наематели на услуги от публичния облак,

и т.н.

Ще приведем няколко примера на такива пробиви в облачната сигурност, за които се коментира и се съобщава официално:



  • Февруари, 201324: "Адаптирането на организацията към услуги от облака веднага повлича след себе си използването на собствените устройства – лаптопи, таблети, интелигентни телефони, ръчни терминали и др. (това е т.нар. концепция "донеси собственото си устройство", на англ. Bring Your Own Device – BYOD). Пробивът във всяко едно такова устройство може да застраши данните на организацията в облака, ако то се използва за работа с наетите услуги.";

  • Октомври, 201425: "MBIA е базирана в Ню Йорк холдингова компания, която предоставя финансова гаранция, застраховки, управление с фиксиран доход на активите, както и други финансови услуги чрез своите дъщерни дружества. Данните, принадлежащи на клиентите на MBIA Inc, най-големият застраховател на облигации в САЩ, по невнимание са експонирани онлайн, поради лошо конфигуриран сървър. Имена на клиенти, счетоводни данни, баланси, дивиденти и друга информация е станала публично достояние и дори е била индексирана от търсачките, тъй като един сървър за отчети не е бил конфигуриран да гарантира, че само оторизирани потребители могат да имат достъп до данни, съобщи блогърът по сигурността Брайън Кребс. Засегнатият сайт е спрян след като от MBIA научават за теча на информация. Google е успял да индексира 230 страници извлечения за лица, като Texas CLASS, Town of Richmond, NH, Connecticut CLASS Plus и New Hampshire Public Deposit Investment Pool.";

  • Октомври, 201426: "Департаментът по заетостта на Орегон разследва проникване на мрежата, което е настъпило на 7 Октомври. Анонимен сигнал, изпратен до организацията, съобщава за уязвимост в сигурността на информационна система WorkSource Oregon Management (WOMIS), където потребителите на системата се регистрират за търсене на работа и свързаните с това услуги. Информацията, която може да е била компрометирана, включва имена, адреси и номера на социални осигуровки. Отделът все още не е предоставил информация за броя на компрометираните записи, нито пълния обхват на нарушението, тъй като и други системи може да са били засегнати. Уязвимата система е била спряна, за да бъде закърпен пробивът, обяви WOMIS. Системата вече е отново онлайн." ;

  • Февруари, 201527: "Близо 40 000 организации, работещи с MongoDB, NoSQL висока производителна платформа бази данни, са незащитени и уязвими за хакери. Трима студенти от Университета в Саарланд, Германия, в Центъра за IT сигурност, откриха, че MongoDB, която работи с TCP порт 27017 като услуга в няколко хиляди търговски уеб сървъри, е оставена лесно достъпна за пробиви. MongoDB е база данни с отворен код, използван от компании от всякакъв мащаб, във всички отрасли, за голямо разнообразие от приложения. MongoDB е построена за скалируемост, производителност и висока надеждност, мащабиране от инсталация на един сървър до големи и сложни архитектури разпределени на няколко места. Германските изследователи заявиха, че те са били в състояние да "четат и пишат" в необезпечени MongoDB бази данни без използването на специални инструменти за хакване. Те открили 39890 MongoDB бази данни, оставени достъпни от Интернет, включително една инстанция, която принадлежи на неназована френска телекомуникационна компания, съдържаща 8 милиона телефонни номера на клиента и адреси. "Всеки може да изтегли и дори да промени няколко милиона единици данни на клиентите, включително имена, адреси, имейли и номера на кредитни карти," твърдят изследователите. Използване на откритата вратичка е невероятно лесно, тъй като нападателят трябва само да провери TCP порт 27017 на машината на жертвата си или може да намери всички възможни уязвими сървъри в Интернет в рамките на четири часа, като сканира, използвайки най-бързият TCP Port скенер наричан "masscan";

  • Февруари, 201528: "Регулаторни изисквания карат предприятията да контролират ключовете, с които криптират данните си, а други организации просто не искат да губят контрол над собствената си информация. Въпреки това, ако една организация иска да използва услугите на доставчик на облачни услуги, тя може да позволи на доставчика достъп до своите ключове. В другият вариант криптирането се извършва в облака с ключове, управлявани от клиента. Напоследът ИТ секторът се фокусира в криптирането, защото от там се очакват решения на проблеми, които са свързани с нарушенията на данни. Ако организацията използва услуги, които надхвърлят простото съхраняване на данни, то контролът над ключовете става дискутабелен проблем. В случай, че доставчикът не може да декриптира данните на клиента, той няма да има възможност да защитава ресурсите на клиента си с антивирусни програми, с инструменти за предпазване от изтичане на данни (DLP), функции за преглед на файлове и индексиране на текст. Не е маловажен и проблемът с процесорното време, което се използва за криптиране и декриптиране. За съжаление доверието в доставчиците на облачни услуги не нараства...".

Изследване на Alert Logic сравнява състоянието на защитата на конвенционалните центрове с тази на доставчиците на облачни услуги. Изследването е направено върху 232364 инцидента по сигурността с повече от милион събития в тях. За това изследване са били установени мухоловки в дейта центровете на множество действащи доставчици на облачни услуги. То показва, че 29:



  • мухоловките в САЩ са атакувани четири пъти повече от тези в Европа. Оказва се, че престъпните групировки от Русия и страните от Източния блок тестват нововъведенията си в Европа, след което насочват изпитаните зловредни софтуерни средства към САЩ;

  • броят на атаките нараства и за облачно базираните дейта центрове и за конвенционалните;

  • с времето атаките се изместват към облачните услуги и очакванията са тази тенденция да продължи заедно с широкото навлизане на новата технология.



1 полезна учебна информация:
Тужаров, Х. http://www.tuj.asenevtsi.com/CN/index.htm
Йорданова, Н. http://193.192.57.240/po/courses/problemni/komputarni%20mrezi/start.html

2 http://pchelp.cablebg.net/Tutorials/Communications/DNS.htm

3 https://tools.ietf.org/html/rfc959

4 https://tools.ietf.org/html/rfc7540

5 http://www-it.fmi.uni-sofia.bg/courses/pc3/beginner/beginner4/content.htm

6 http://www.faqs.org/faqs/client-server-faq/

7 http://www.sei.cmu.edu/str/descriptions/clientserver_body.html

8 Hoffer, J.A., Prescott, M.B., McFadden, F.R., Modern Database Management, Seventh Edition, Prentice Hall, 2005.

9 http://blog.icn.bg/%D0%BD%D0%BE%D0%B2%D0%B8%D0%BD%D0%B8-%D0%BE%D1%82-icn-bg/%D0%BE%D0%B1%D0%BB%D0%B0%D1%87%D0%BD%D0%B8-%D1%82%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D0%B8-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8/

10 http://oblachnitehnologii.weebly.com/1057109810971085108610891090.html

11 www.gartner.com

12 http://nslatinski.org/?q=bg/node/370

13 http://nslatinski.org/?q=bg/node/370

14 http://iniod.com/wp-content/uploads/2013/09/%D0%98%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0-%D1%81%D0%B8%D0%B3%D1%83%D1%80%D0%BD%D0%BE%D1%81%D1%82.pdf

15 http://www.utilities.bg/show.php?storyid=577624

16 http://www.mrcmekong.org/download/programmes/ep/Aust_Standards_4360-2004.pdf

17 http://www.iso.org/iso/home/standards.htm

18 полезна учебна информация:
Йорданова, Н. http://193.192.57.240/po/courses/problemni/komputarni%20mrezi/start.html

19 Велиян Димитров Проблеми при защита на данните в "облака" – важните въпроси към вашият доставчик на услуги (част 2)

20 LeeBadger Tim Grance RobertPatt-Corner JeffVoas. Draft cloud computing synopsis and recommendations. In Recommendations of the National Institute of Standards and Technology, NIST Special Publication 800-146, May 2011.

21 Symantec official blog. http://www.symantec.com/connect/blogs/are-clouds-change-looming-over-perimeter-security. Are Clouds of Change Looming over Perimeter Security?, August 2012.

22 JERICO FORUM. https://collaboration.opengroup.org/jericho/architecture_v1.0.pdf. Position Paper Architecture for De-perimeterisation, April 2006.

23 LEE Kwok Keong. Royal holloway university of london, department of mathematics, technical report rhul-ma-2009-07. Management of Risks associated with De-perimeterisation, February 2009.

24 http://cio.bg/5223_problemi_pri_zashtita_na_dannite_v_oblaka_­_izpolzvane_na_bazi_danni_fajlovi_uslugi_i_koshmarat_byod_chast_1

25 http://www.securityweek.com/us-bond-insurer-mbia-exposed-sensitive-customer-data?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Securityweek+%28SecurityWeek+RSS+Feed%29

26 http://www.tripwire.com/state-of-security/latest-security-news/security-breach-at-oregon-employment-department/

27 http://expert.idg.bg/isecurity/5634_hakerska_operaciya_s_rezultat_300_miliona/

28 http://www.technewsworld.com/story/81711.html

29 http://www.rackspace.com/knowledge_center/whitepaper/alert-logic-cloud-security-report-spring-2014-research-on-the-evolving-state-of-cloud


Каталог: materials
materials -> Исторически преглед на възникването и развитието на ес
materials -> Съюз на математиците в българия-секция русе коледно математическо състезание – 12. 2006 г. 4 клас
materials -> Великденско математическо състезание 12. 04. 2008 г. 2 клас Времето за решаване е 120 минути
materials -> Съюз на математиците в българия-секция русе коледно математическо състезание – 09. 12. 2006г
materials -> Съюз на математиците в българия-секция русе коледно математическо състезание – 12. 2006 г. 8 клас
materials -> Великденско математическо състезание 12. 04. 2008г. 3 клас
materials -> К а т е д р а " информатика"
materials -> Зад. 2 Отг.: 5- 3т Зад. 3 Отг.: (=,-);(+,=);(+,=) по 1т., общо 3т. За
materials -> Іv клас От 1 до 5 зад по 3 точки, от 6 до 10 – по 5 и от 11 до 15 – по 7


Сподели с приятели:
1   ...   11   12   13   14   15   16   17   18   19




©obuch.info 2024
отнасят до администрацията

    Начална страница