Я уже не однажды касал­ся воп­росов безопас­ности в AWS в том или ином кон­тек­сте. На этот раз я решил рас­ска­зать про основные механиз­мы безопас­ности, а так­же про типовые граб­ли, на которые нас­тупа­ют счас­тли­вые адми­ны и раз­работ­чики. Поп­робу­ем обоб­щить и сис­темати­зиро­вать тре­бова­ния и необ­ходимые про­цеду­ры по обес­печению надеж­ной защиты сер­висов, которые мы хотим раз­вернуть в обла­ке Amazon’a.
 

Защищай аккаунт

Са­мое цен­ное, что есть у тебя, — это админ­ский дос­туп к акка­унту. Он поз­воля­ет соз­давать/уда­лять инстан­сы, управлять ролями и клю­чами, прик­реплять секури­ти‑груп­пы, нас­тра­ивать роутинг, менять нас­трой­ки балан­сера, менять сер­тифика­ты SSL и мно­гое дру­гое. Этот дос­туп надо защищать, впро­чем, как и любой дру­гой дос­туп к админ­ской (и не толь­ко) кон­соли, — ведь может быть мно­го поль­зовате­лей, ролей и клю­чей.

Аутентификация: логин + пароль

Клас­сика жан­ра, добавить тут нечего, кро­ме раз­ве что пары вещей: пароль­ной полити­ки и двух­фактор­ной аутен­тифика­ции. AWS поз­воля­ет нас­тро­ить полити­ку, которая будет огра­ничи­вать минималь­ную дли­ну пароля, зас­тавлять исполь­зовать регис­тры, циф­ры и спец­симво­лы, ну и так­же про­верять обновле­ние пароля в течение опре­делен­ного сро­ка, а кро­ме того, запоми­нать хеш пре­дыду­щих N паролей, что­бы поль­зователь не смог их исполь­зовать пов­торно. Короче, прос­то и понят­но. Двух­фактор­ка тоже не инно­вация — исполь­зуй хар­двар­ный или вир­туаль­ный MFA, генера­тор одно­разо­вых паролей, который будет их генери­ровать каж­дые 30 секунд, таким обра­зом ты дол­жен ввес­ти логин + пароль + одно­разо­вый код. Вир­туаль­ный MFA может быть уста­нов­лен на телефо­не. Все вмес­те это доволь­но стан­дар­тное и надеж­ное средс­тво защиты пароль­ной аутен­тифика­ции.

Настройка парольных политик — классика!
Нас­трой­ка пароль­ных политик — клас­сика!

Аутентификация по симметричному ключу

Но это не единс­твен­ный спо­соб, есть еще клю­чи дос­тупа, которые при­вязы­вают­ся к поль­зовате­лю. Клю­чи генери­руют­ся пря­мо из кон­соли и могут быть ска­чаны в виде фай­ла. Фак­тичес­ки это прос­то длин­ная, слу­чай­ная стро­ка, как пароль, толь­ко явля­ется клю­чом (сим­метрич­ного крип­тоал­горит­ма). Этот ключ сек­ретный и хра­нит­ся на сер­вере и у кли­ента. Он исполь­зует­ся для дос­тупа к REST API и при­вязан к кон­крет­ному поль­зовате­лю. И если про логин и пароль все ясно, то к это­му клю­чу почему‑то раз­работ­чики отно­сят­ся менее серь­езно. Доволь­но час­то быва­ет, что его мож­но най­ти в исходни­ках на GitHub’е или зашитым в исходни­ки Android/iOS-при­ложе­ния. А ведь это ключ дос­тупа, и если юзер это­го клю­ча — админ, то и любой API-зап­рос — админ­ский, вклю­чая зап­рос на соз­дание нового поль­зовате­ля или инстан­са. Поэто­му ключ надо защищать, это важ­ный момент.

Подписанные запросы API (SOAP)

Кро­ме сим­метрич­ной крип­тогра­фии, AWS поз­воля­ет исполь­зовать асим­метрич­ную. Ты генери­руешь RSA-клю­чи, дела­ешь сер­тификат с откры­тым клю­чом, прик­репля­ешь этот сер­тификат к поль­зовате­лю в AWS-кон­соли, пос­ле чего можешь исполь­зовать SOAP API с XML signatures (не вез­де, в EC2/S3, нап­ример, толь­ко REST, толь­ко хар­дкор, там лишь Access Key). Естес­твен­но, зак­рытую часть клю­ча надо защищать…

Ро­тацию клю­чей/сер­тифика­тов мож­но и нуж­но под­держи­вать! Все перечис­ленные методы и нас­трой­ки — часть так называ­емо­го AWS IAM (AWS Identity and Access Management) и могут быть нас­тро­ены как через API или шаб­лоны (AWS CloudFormation), так и вруч­ную в кон­соли.

 

Роли и группы

Не все поль­зовате­ли дол­жны быть адми­нами, это оче­вид­но, поэто­му AWS IAM име­ет еще сущ­ности: роли, груп­пы и полити­ки. Полити­ка — это опи­сание дос­тупа. Нап­ример, админ­ская полити­ка выг­лядит так:

{
"Statement":[{
"Effect":"Allow",
"Action":"*",
"Resource":"*"
}
]
}

По‑деревен­ски: раз­решать делать ВСЕ для ВСЕ­ГО. Соот­ветс­твен­но, огра­ничи­ваем пра­ва для дос­тупа к IAM так:

"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:GetGroup",
"iam:GetLoginProfile",
"iam:GetUser",
"iam:ListAccessKeys",
"iam:ListAccountAliases",
"iam:ListGroupPolicies",
"iam:ListGroups",
"iam:ListGroupsForUser",
"iam:ListMFADevices",
"iam:ListSigningCertificates",
"iam:ListUsers",
"iam:GetServerCertificate",
"iam:ListServerCertificates",
],
"Resource": "*"
}
]
  • Effect — раз­решить или зап­ретить.
  • Action — какой зап­рос API кон­крет­но, то есть какое дей­ствие.
  • Resource — какой кон­крет­но ресурс может быть объ­ектом для дан­ной полити­ки, в дан­ном кон­тек­сте IAM — груп­па или поль­зователь, на которых рас­простра­няют­ся эти пра­вила (в нашем при­мере это все груп­пы и поль­зовате­ли).

Еще есть допол­нитель­ная груп­па Condition, в которой мож­но ука­зать допол­нитель­ные усло­вия политик, нап­ример IP-адрес источни­ка (филь­тр по IP).

Ну и понят­на логика для Actions: все, что не раз­решено, зап­рещено. Эти полити­ки мож­но при­писать как роли, так и отдель­но поль­зовате­лю. Потом на осно­ве ролей соз­давать груп­пы. При этом груп­пу мож­но так­же наз­начить поль­зовате­лю. То есть мож­но «давать пра­ва» либо поль­зовате­лям, либо ролям, которые вхо­дят в груп­пы. Поль­зовате­лям мож­но сос­тоять в одной груп­пе или в нес­коль­ких. То есть получа­ется весь­ма гиб­кая ролевая модель.

При доволь­но боль­шой инфраструк­туре, где у нас мно­го поль­зовате­лей — для деп­лоя, для ска­нера, для ауди­та, для логов и так далее, есть веро­ятность намуд­рить и запутать­ся — очень мно­го пра­вил: одним мож­но писать в s3, дру­гим толь­ко читать… И конеч­но, это огромное поле для сок­рытия бэк­дора :). Нап­ример, бэк­дорная полиси может быть добав­лена в роль или к поль­зовате­лю, при этом спи­сок поль­зовате­лей, ролей и групп не изме­нит­ся.

 

Еще больше доступа к аккаунту

Ка­залось бы, точ­ки вхо­да и пра­ва — все оно тут есть и опи­сано. Но есть еще мно­го чер­ных ходов.

Доверенные аккаунты

На роль мож­но при­цепить юзе­ра с дру­гого акка­унта. Это очень мило, берем роль адми­на и цеп­ляем к нему поль­зовате­ля с хакер­ско­го акка­унта. Заметить это мож­но толь­ко в гра­фе Trusted Relationship в спис­ке ролей — в спис­ке поль­зовате­лей его вид­но не будет.

Роль инстанcа

Все инстан­сы могут обра­щать­ся к API метадан­ных без клю­ча latest/meta-data. С это­го API инстанс (и хац­кер, который запыв­нил бокс) может получить кучу инфы. Иро­ния в том, что мож­но при­цепить роль к самому инстан­су, таким обра­зом мож­но исполь­зовать AWS API, и тог­да будет генери­ровать­ся вре­мен­ный Access Key, который мож­но слить через эти же метадан­ные: latest/meta-data/iam/security-credentials/ROLE_NAME.

Ис­поль­зуя этот ключ, мож­но делать то, что про­писа­но в полити­ках роли. То есть фак­тичес­ки дос­таточ­но прос­той SSRF, что­бы пол­ностью зах­ватить акка­унт (при излишне небезо­пас­ных нас­трой­ках, конеч­но).

Слив ключей доступа через SSRF для роли инстанса
Слив клю­чей дос­тупа через SSRF для роли инстан­са

SAML Providers

А ведь мож­но еще добавить про­вай­дер для SSO-аутен­тифика­ции. То есть где‑то у тебя есть, нап­ример, свой LDAP, мож­но добавить его в AWS-акка­унт, тог­да аутен­тифика­ция юзе­ра будет про­ходить там, и в слу­чае успе­ха дос­туп этот юзер получит в AWS-акка­унте с опре­делен­ной ролью...

 

Защищаем инстансы

Да, вто­рая часть защиты обла­ка — это защита непос­редс­твен­но вир­туалок. В 90% это воп­росы защиты ОС, сер­висов и про­чие баяны. Глав­ное — пом­нить нес­коль­ко момен­тов: инстан­сы име­ют дос­туп к API AWS, инос­тран­цы могут иметь дос­туп к внут­ренней сети и к дру­гим инстан­сам и даже к локаль­ной сети или ЦоД за пре­дела­ми AWS. Это я на тему SSRF-атак или в слу­чае ком­про­мета­ции бок­са про раз­витие атак. Так или ина­че, кро­ме механиз­мов защиты ОС, есть еще и механиз­мы AWS, и это уже выше­упо­мяну­тые VPC, а кро­ме того, Security Groups и ELB сег­мента­ция сети, даже вир­туаль­ной, — это доволь­но важ­но.

VPC (Amazon Virtual Private Cloud)

Фак­тичес­ки это воз­можность рулить локаль­ными под­сетями — с филь­тра­цией и роутин­гом тра­фика так, как удоб­но кли­енту. Нап­ример, мож­но про­кинуть VPN из дата‑цен­тра или офи­са в под­сетку нашего ама­зона, объ­еди­нив их в некую логичес­кую под­сеть. А мож­но прос­то напили­вать зоны типа DMZ, бэкенд и так далее. Этот механизм силь­но рас­ширя­ет наши воз­можнос­ти по срав­нению со стан­дар­тным EC2.

Security Groups

Это обыч­ный спо­соб филь­тро­вать тра­фик меж­ду инстан­сами. Фак­тичес­ки это прос­той спи­сок с пра­вила­ми филь­тра­ции — отку­да, куда, какой порт. Кро­ме того, если говорить о филь­тра­ции в VPC, там есть отдель­ные пра­вила филь­тра­ции меж­ду сетями — Network ACL. А Security Groups при­мени­мы непос­редс­твен­но к инcтан­сам. Хотя дан­ный механизм доволь­но неудо­бен, так как име­ет ряд огра­ниче­ний: в EC2 нель­зя добав­лять груп­пы к уже сущес­тву­ющим инстан­сам. Либо менять текущие груп­пы, либо передеп­лоить инстанс уже с новым сетом групп.

ELB (Elastic Load Balancing)

Дан­ная сущ­ность явля­ется «встро­енным» балан­сером, а так­же может играть роль SSL-тер­минато­ра, так что пос­ле генера­ции клю­чика и сер­тифика­та SSL они апло­адят­ся имен­но туда. Опять же есть косяк — в EC2 нель­зя при­лепить филь­тра­цию к балан­серам, то есть если ты хочешь огра­ничить дос­туп с опре­делен­ных IP. ELB дос­тупен для всех, всег­да. Вто­рой косяк, даже еще более мер­зкий, — если у тебя SSL за ELB, то ты теря­ешь Source IP — X-Forwarded-For не добав­ляет­ся к заголов­ку (зашиф­рован). Ну а если ты фор­вардишь SSH через ELB, то да... это про­вал :).

Все три опи­сан­ных механиз­ма поз­волят филь­тро­вать и раз­давать тра­фик более про­думан­но с точ­ки зре­ния безопас­ности, впро­чем, как и соз­давать дыры и проб­лемы…

 

CloudFormation

Важ­ная часть безопас­ности — это уни­фика­ция и стан­дарти­зация кон­фигов, дос­тупа и про­чего. То есть один раз кон­фигури­руем типовое решение, про­веря­ем, что безопас­но, удоб­но и быс­тро, — далее при­меня­ем. Это поз­волит избе­жать велоси­педов и сни­зить «челове­чес­кий фак­тор», ну и глав­ное — удоб­но монито­рить. Задали, допус­тим, секури­ти‑груп­пе имя — и зна­ем, что это за груп­па, что там, про что она, а ина­че была бы куча оди­нако­вых групп на раз­ных акках с раз­ными наз­вани­ями. И еще надо убе­дить­ся, что и внут­ри все ОК.

 

CloudTrail

Ес­ли у нас нет логиро­вания событий AWS, то все доволь­но печаль­но. Кто и ког­да поль­зовал­ся API? Кто логинил­ся? Кто менял полити­ки и пря­тал бэк­дор? Все это будет тебе неиз­вес­тно. Очень важ­ный эле­мент безопас­ности для монито­рин­га и рас­сле­дова­ния инци­ден­тов. Ана­лиз логов мож­но и нуж­но авто­мати­зиро­вать, но про это я уже писал, прос­то не мог не упо­мянуть тут ;).

 

Регионы

Оче­вид­но, но все же тема важ­ная. Акка­унт делит­ся на реги­оны, и если IAM-поль­зовате­ли, нап­ример, на весь акка­унт, то уже инстан­сы и полити­ки — нет. Тот же CloudTrail может быть нас­тро­ен не на все реги­оны. Этот момент надо пом­нить и кон­тро­лиро­вать, собс­твен­но, как я писал выше, — оче­вид­ная вещь, но забывать не сто­ит.

 

Финал

Мно­гое тут не умес­тилось, но, наде­юсь, глав­ное показать уда­лось — тон­кие мес­та в нас­трой­ках, архи­тек­туре или мес­та для бэк­дора (осо­бен­но в полити­ках). Короче, основные узлы безопас­ности акка­унта AWS и, как следс­твие, всей облачной плат­формы. Если что, пред­лагаю вспом­нить исто­рию одной ком­пании, у которой укра­ли акк от AWS, соз­дали бэк­дор, и, ког­да те попыта­лись почис­тить­ся, зло­деи все уда­лили, так как име­ли аль­тер­натив­ный дос­туп к акка­унту. В ито­ге ком­пания зак­рыла свой биз­нес. Всем безопас­ных и при­ятных обла­ков!

Алексей Синцов

Известный white hat, докладчик на security-конференциях, соорганизатор ZeroNights и просто отличный парень. В данный момент занимает должность Principal Security Engineer в компании Nokia, где отвечает за безопасность сервисов платформы HERE

Check Also

Номер триста. Колонка главреда

О приближении трехсотого номера коллеги начали мне напоминать примерно два года назад: ког…

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии