Заплахите за сигурността на нашите безсървърни приложения приемат много форми. Някои са стари врагове, с които сме се сблъсквали и преди. Някои са нови. А някои са приели нови форми в света без сървъри.

Тъй като възприемаме безсървърната парадигма, ние делегираме още повече оперативни отговорности на нашите облачни доставчици. С AWS Lambda вече не е нужно да конфигурирате AMI, да кръпвате операционната система и да инсталирате демони за наблюдение. AWS се грижи за всичко това вместо вас.

Какво означава това за Модела на споделена отговорност, който отдавна е крайъгълният камък на сигурността в облака на AWS?

Защита от атаки срещу ОС

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

По този начин той ни защитава от атаки срещу известни уязвимости в операционната система и предотвратява атаки като WannaCry.

Като премахваме дълготрайните сървъри от картината, ние премахваме и заплахите, породени от компрометирани сървъри, които живеят в нашата среда за дълго време.

Въпреки това все още е наша отговорност да коригираме нашето приложение и да адресираме уязвимостите, които съществуват в нашия код и нашите зависимости.

Топ 10 на OWASP все още е актуален както винаги

Един поглед към OWASP топ 10 за 2017 г. ни показва познати заплахи. Атаките чрез инжектиране, нарушената автентификация и междусайтовото скриптиране (XSS) все още заемат първите места седем години по-късно.

A9 — Компоненти с известни уязвимости

Когато хората от Snyk разгледаха набор от данни за 1792 нарушения на данните през 2016 г., те откриха, че 12 от най-големите 50 нарушения на данни са причинени от приложения, използващи компоненти с известни уязвимости.

Освен това, 77% от топ 5000 URL адреса от Alexa включват поне една уязвима библиотека. Това е по-малко изненадващо, отколкото звучи на пръв поглед, като вземете предвид, че някои от най-популярните предни js рамки – напр. jQuery, Angular и React — всички имаха известни уязвимости. Той подчертава необходимостта от непрекъснато актуализиране и корекция на вашите зависимости.

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

И тогава има въпрос на преходни зависимости. Ако тези преходни зависимости имат уязвимости, тогава вие също сте уязвими чрез преките си зависимости.

Намирането на уязвимости в нашите зависимости е трудна работа и изисква постоянно усърдие. Ето защо услуги като Snyk са толкова полезни. Той дори идва с вградена интеграция с Lambda!

Атаки срещу издатели на NPM

Миналата година ловец на глави в областта на сигурността успя да спечели права за директно изпращане на 14% от NPM пакетите. Списъкът със засегнатите пакети включва и някои големи имена: debug, request, react, co, express, moment, gulp, mongoose, mysql, bower, browserify, electron, jasmine, cheerio, modernizr, redux и много други. Общо тези пакети представляват 20% от общия брой месечни изтегляния от NPM.

Оставете това да се разбере за момент.

Използвал ли е сложни методи, за да заобиколи сигурността на NPM?

Не, беше комбинация от груба сила и използване на известен акаунт и изтичане на идентификационни данни от редица източници, включително Github. С други думи, всеки би могъл да ги направи с много малко изследвания.

Трудно е да не се почувствате разочаровани от тези автори на пакети, когато толкова много демонстрират такова кавалерско отношение към осигуряването на достъп до своите NPM акаунти.

662 потребители имаха парола «123456», 174 — «123», 124 — «password».

1409 потребители (1%) са използвали потребителското си име като парола в оригиналния му вид, без никакви промени.

11% от потребителите са използвали повторно своите изтекли пароли: 10,6% — директно и 0,7% — с незначителни модификации.

Както демонстрирах в моя разговор относно сигурността без сървър, можете да откраднете временни идентификационни данни за AWS, като добавите няколко реда код.

Представете си тогава сценарий, при който нападател е успял да получи права за предаване на 14% от всички NPM пакети. Той може да публикува актуализация на кръпка за всички тези пакети и да открадне идентификационни данни на AWS в огромен мащаб.

Залозите са високи и това е може би най-голямата заплаха за сигурността, с която се сблъскваме в света без сървъри. И също така засяга приложения, работещи в EC2 или контейнери.

Проблемите и рисковете с управлението на пакети не са специфични за екосистемата Node.js. Прекарах по-голямата част от кариерата си в работа с .Net и сега Scala, а управлението на пакети беше предизвикателство навсякъде. Нуждаем се от авторите на пакети, за да полагат необходимото внимание към сигурността на своите акаунти.

A1 — Инжекция & A3 — XSS

SQL инжектиране и други форми на инжектиране на атаки все още са възможни в света без сървъри. Както и Cross-Site Scripting (XSS) атаките.

Дори ако използвате NoSQL бази данни, може да не сте в безопасност и от атаки чрез инжектиране. MongoDB, например, разкрива редица „вектори на атака“ чрез своите API за заявки.

По-строгият API на DynamoDB прави атаката чрез инжектиране по-трудна. Но все още сте отворени за други форми на подвизи. Например XSS и изтекли идентификационни данни, които предоставят на атакуващия достъп до DynamoDB таблици.

Независимо от това, винаги трябва да дезинфекцирате потребителските входове, както и изхода от вашите Lambda функции.

A6 — Разкриване на чувствителни данни

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

Трой Хънт демонстрира как можем случайно да разкрием всички видове чувствителни данни, като оставим ВКЛЮЧЕНИ опциите за списък с директории. От web.config, съдържащ идентификационни данни (в 35:28) до SQL архивни файлове (в 1:17:28)!

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

АЗ СЪМ

Ако вашите функции са компрометирани, следващата линия на защита е да ограничите какво могат да направят компрометираните функции.

Ето защо трябва да приложите Принципа на най-малките привилегии, когато конфигурирате разрешения за Lambda.

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

Спецификацията serverless.yml обаче ви позволява да посочите различна IAM роля за функция. Но това включва много повече усилия за разработка и добавя достатъчно напрежение, така че почти никой не прави това.

За щастие, Guy Lichtman създаде плъгин за рамката Serverless, наречена serverless-iam-role-per-function. Този плъгин прави много по-лесно прилагането на IAM роли за всяка функция. Следвайте инструкциите на страницата на Github и опитайте сами.

IAM политиката не е версия с Lambda

Недостатък на Lambda и IAM конфигурацията е, че IAM политиките не се версират с Lambda функцията.

Ако имате няколко версии на една и съща функция в активна употреба (може би с различни псевдоними), тогава става проблематично да добавите или премахнете разрешения:

  • Добавянето на разрешения към нова версия позволява на по-старите версии повече достъп, отколкото им е необходим
  • Премахването на разрешения от нова версия може да повреди по-старите версии, които все още се нуждаят от тези разрешения

Преди 1.0 това беше често срещан проблем с рамката Без сървър, защото използваше псевдоними за внедряване на етапи. От 1.0 това вече не е проблем, тъй като всеки етап е разгърнат като отделна функция. Например:

  • service-function-dev
  • service-function-staging
  • service-function-prod

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

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

Изтрийте неизползваните функции

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

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

Документацията на Lambda също цитира това като една от „най-добрите практики“.

Изтрийте стари Lambda функции, които вече не използвате.

Променящото се лице на DoS атаките

С AWS Lambda е много по-вероятно да се измъкнете от атака на отказ от услуга (DoS). Въпреки това, агресивното мащабиране на вашата безсървърна архитектура за борба с DoS атака с груба сила има значително отражение върху разходите.

Нищо чудно, че хората започнаха да наричат ​​DoS атаките срещу безсървърни приложения Denial of Wallet (DoW) атаки!

„Но можете просто да намалите не. на едновременни извиквания, нали?“

Разбира се, и вместо това се оказвате с проблем с DoS... това е ситуация на загуба.

Разбира се, има AWS Shield. Срещу фиксирана такса AWS Shield Advanced ви осигурява защита при плащане в случай на DoS атака. Но към момента на писане тази защита не покрива разходите за Lambda.

Освен това Lambda има поне веднъж политика за извикване. „Според хората от SunGard“, това може да доведе до до три (успешни) извиквания. От статията отчетеният процент на многократни извиквания е изключително нисък - 0,02%. Но човек се чуди дали скоростта е свързана с натоварването и може да се прояви с много по-висока скорост по време на DoS атака.

Освен това трябва да обмислите как Lambda „опитва повторно неуспешни извиквания“ от „асинхронен източник“. Например S3, SNS, SES и CloudWatch събития.

Официално тези извиквания се опитват два пъти, преди да бъдат изпратени до присвоената опашка за мъртви писма (DLQ), ако такава е конфигурирана. Въпреки това, „анализ“ от OpsGenie показа, че броят на повторните опити може да достигне до 6, преди извикването да бъде изпратено до DLQ.

Ако DoS атакуващият е в състояние да задейства неуспешни асинхронни извиквания, тогава той може да увеличи въздействието на своята атака.

Например, ако вашето приложение позволява на клиента да актуализира файл до S3 за обработка. След това атакуващият може да ви направи DoS, като качи голям брой невалидни файлове, които ще доведат до грешки във вашите функции и повторен опит.

Всичко това допринася за потенциала за експлодиране на действителния брой извиквания на Lambda по време на DoS атака. Както обсъдихме по-рано, докато вашата инфраструктура може да успее да се справи с атаката, може ли портфейлът ви да се разтегне до същата степен? Трябва ли да го позволите?

Защита на външни данни

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

Комуникацията с всички AWS услуги се осъществява чрез HTTPS и всяка заявка се подписва и удостоверява. Няколко услуги на AWS също предлагат криптиране от страна на сървъра за вашите данни в покой. Например S3, RDS и Kinesis streams изникват на ум. Lambda също има вградена интеграция с KMS за криптиране на променливи на средата.

Наскоро DynamoDB също обяви "поддръжка за криптиране в покой".

Същото старание трябва да се прилага при съхраняване на чувствителни данни в услуги/бази данни, които не предлагат вградено криптиране. В случай на нарушение на сигурността на данните, той осигурява още едно ниво на защита за данните на вашите потребители.

Толкова дължим на потребителите си.

Използвайте защитен транспорт при предаване на данни към и от услуги (както външни, така и вътрешни). Ако създавате API с API Gateway и Lambda, тогава сте принудени да използвате HTTPS по подразбиране, което е нещо добро. Крайните точки на API Gateway обаче винаги са публични, трябва да вземете необходимите предпазни мерки, за да осигурите достъп до вътрешни API.

Трябва да използвате IAM роли, за да защитите вътрешните API. Той ви дава „прецизен контрол“ върху това кой може да извиква какви действия на какви ресурси. Използването на IAM роли също ви спестява от неудобни разговори като този:

„Това е последният ден на X, той вероятно има нашите API ключове някъде в лаптопа си, трябва ли да завъртим API ключовете за всеки случай?“

„Хм.. това би било много работа, X заслужава доверие и няма да направи нищо.“

„Добре… щом така казваш… (тайно се моли Х да не изгуби лаптопа си или да развие закъсняла злоба към компанията)“

За щастие, това може да бъде лесно конфигурирано с помощта на рамката Serverless.

Изтекли идентификационни данни

Интернет е пълен с ужасяващи истории за разработчици, трупащи огромна сметка за AWS, след като техните изтекли идентификационни данни са използвани за копаене на биткойни. За всяка подобна история много повече са били засегнати, но са предпочели да замълчат. По същата причина много пробиви в сигурността не се разкриват публично, тъй като компаниите не искат да загубят лицето си.

Дори в моя малък социален кръг знам за два подобни инцидента. Нито един от тях не беше публикуван и двата доведоха до щети на стойност над $100 000. За щастие и в двата случая AWS се съгласи да покрие разходите.

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

Добър подход за предотвратяване на изтичане на идентификационни данни на AWS е използването на кукички за предварително ангажиране на Git, както е посочено в тази публикация.

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

Изводи

В тази публикация разгледахме редица заплахи за сигурността на нашите приложения без сървър. Много от тях са същите заплахи, които измъчват софтуерната индустрия от години. Всички топ 10 на OWASP все още се отнасят за нас, включително SQL, NoSQL и други форми на инжекционни атаки.

Изтеклите идентификационни данни за AWS остават основен проблем и могат да повлияят на всяка организация, която използва AWS. Въпреки че има доста публично съобщени инциденти, имам силното чувство, че действителният брой инциденти е много по-голям.

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

Положително е, че AWS поема отговорността за сигурността на хост операционната система ни дава редица предимства за сигурността:

  • Защита срещу атаки на операционната система, тъй като AWS може да свърши много по-добра работа за коригиране на известни уязвимости в операционната система
  • Хост ОС са ефимерни, което означава, че няма дълготрайни компрометирани сървъри

С API Gateway и Lambda вече не се нуждаете от уеб рамки за създаване на API. Без уеб рамки няма лесен начин за поддръжка на списък с директории. Но това е хубаво нещо, защото прави директория, изброяваща кратко дизайнерско решение. Край на случайното разкриване на чувствителни данни чрез неправилно конфигуриране.

DoS атаките са приели нова форма в света без сървъри. Въпреки че сте в състояние да се измъкнете от атака, тя пак ще ви нарани в портфейла. Разходите за Lambda, направени по време на DoS атака, не се покриват от AWS Shield Advancedкъм момента на писане.

Междувременно с AWS Lambda се появиха някои нови повърхности за атака:

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

Преди всичко най-тревожната заплаха за мен са атаките срещу самите автори на пакета. Много автори не приемат сериозно сигурността на акаунтите си. Това застрашава самите тях, както и останалата част от общността, която зависи от тях. Трудно е да се предпазим от подобни атаки и подкопаваме един от най-силните аспекти на всяка софтуерна екосистема – общността, която стои зад нея.

За пореден път се доказа, че хората са най-слабото звено във веригата за сигурност.