Как да изградим сигурна и надеждна архитектура на облака AWS, без да си загубим ума

Въведение

Ако някога сте се опитвали да проектирате облачна архитектура в AWS от нулата, вероятно вече знаете: това е еднаква част свобода и хаос. Съществуват хиляди начини да се изгради нещо и също толкова начини да се обърка.

Един кратък поглед към документацията на AWS може да ви остави да си помислите: "Готино, просто ще спазваме първокласните практики". Но в реална международна среда първокласните практики нерядко се сблъскват с реалните нужди на търговското предприятие, ограниченията на ценовия диапазон или човешката грешка. Ето защо работата с професионалисти като perfsys в началото може да предотврати хазартни игри с дупки в защитата и усложнения при мащабирането по-късно.

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

Да започнем с очевидното: AWS е звяр

С AWS можете да създадете практически всичко. От стартъпи с двама души до огромни корпоративни платформи, всички градивни елементи са налице - EC2, Lambda, RDS, S3, IAM, VPC, списъкът продължава. Уловката? Колкото повече възможности имате, толкова по-лесно е да създадете заплетена каша.

Не че AWS е лошо проектирана. Просто трябва да я проектирате правилно. В противен случай се получава това, което някои екипи наричат "облачни спагети": взаимозависими услуги, твърдо кодирани тайни, никакво маркиране, никакво регистриране и абсолютно никаква представа кое колко струва.

Надеждността и сигурността не са нещо хубаво

Изкушаващо е да разглеждаме сигурността и надеждността като проблем на бъдещето. "Ще го подсигурим, след като го пуснем в действие." "Ще добавим мониторинг в следващия спринт." Но попитайте всеки, който се е сблъсквал с нарушаване на сигурността на данните или с многочасово прекъсване на работата - пропускането на тези стъпки е начинът, по който в крайна сметка ще ви се наложи да спите цяла нощ.

Какво наистина означава надеждност

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

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

А сигурността? Това не е само IAM

Да, управлението на идентичността и достъпа (IAM) е първата стена. Но сигурността се простира далеч отвъд нея. Публично достъпни кофи S3. Роли с прекомерни права. Тайните, кодирани в Lambda функциите. Изключено регистриране "за да се спестят разходи". Всичко това са бомби със закъснител.

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

Градивните елементи, които всъщност имат значение

Добре, нека преминем към същността на въпроса. Ето какво има значение, когато изграждате сигурна и надеждна архитектура в AWS - и къде екипите най-често грешат.

Използване на IAM ролите по правилния начин (да, наистина)

Ролите на IAM са мощни. Понякога са твърде мощни. Твърде лесно е да си сложите "AdministratorAccess", защото нещо не работи, да обещаете да го поправите по-късно... и след това никога да не го поправите.

Трябва да го фиксирате отрано. Принципът на най-малките привилегии не е просто добра практика - това е единственият разумен начин за работа. Това означава:

• Разпределение на ролите по услуги

• Избягване на заместващи символи в разрешенията

• Краткотрайни пълномощия

• Задължително MFA за потребителите

Звучи ли ви болезнено? Така е. Но същото е и да обяснявате на шефа си защо някой е ексфилтрирал данни за клиенти от неправилно конфигурирана Lambda.

Разделете мрежата си така, както го мислите

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

• Публични подмрежи само за неща, които трябва да са насочени към интернет (напр. ALB)

• Частни подмрежи за всичко останало

• NAT шлюзове за контролиран изходящ достъп

• крайни точки на VPC за трафика на услугите на AWS, без да се стига до публичния интернет

Плосък VPC с всичко в една и съща подмрежа може да изглежда лесно. Докато нещо не се счупи и не отнесе всичко със себе си.

Регистриране и наблюдение: Не можете да поправите това, което не виждате

Това вече не би трябвало да се обсъжда. Регистрирането не е по избор. Ако не улавяте CloudTrail, метриките на CloudWatch и логовете на потоците на VPC, летите на сляпо.

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

Криптирайте всичко (без изключения)

Използвайте KMS за данни в покой. Използвайте TLS за данни при пренос. Ротирайте ключовете. Наблюдавайте достъпа. Това е една от областите, в които мързелът сега струва много скъпо по-късно.

Не забравяйте и за неща като криптиране на RDS, настройки на обема на EBS и налагане на TLS на API Gateway. Тези малки детайли се натрупват.

Инфраструктура като код или провал

Все още внедрявате, като щракате в конзолата на AWS? Това е добре за разработчици, но е опасно за продавачи.

Използвайте Terraform, CloudFormation или CDK. Каквото предпочита екипът ви - просто изберете едно и се придържайте към него. Контролирайте версиите на шаблоните си. Използвайте CI/CD за разгръщане. Автоматизирайте връщането назад. Ръчното разгръщане е отворена покана за грешки.

Също така: маркирайте всичко. Ресурсите без етикети са като кабели без етикети - никой не знае за какво са и всички се страхуват да ги докоснат.

Мащабиране без потъване

Нека да е ясно: AWS обича, когато предоставяте прекалено много ресурси. Вие получавате "производителност", а те получават парите ви. Ефективното мащабиране се състои в това да познавате моделите си - и да планирате за тях.

Използвайте групи за автоматично мащабиране, спот инстанции (внимателно) и слоеве за кеширане. Но по-важното е, че тествайте при натоварване. Последното нещо, което искате, е да откриете, че вашата RDS инстанция се топи под реален трафик два дни след стартирането.

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

Плановете за възстановяване след бедствие не са задължителни

Какво се случва, ако даден регион се срине? Какво става, ако основната ви база данни се повреди? Ако отговорът е "ами... ще имаме проблеми", значи е време да преработите стратегията си за възстановяване.

Това не означава да изградите идентично копие на инфраструктурата си в друг регион. Това означава да знаете:

• Какво ще възстановите

• Колко време ще отнеме

• Какви данни ще бъдат загубени (ако има такива)

• Кой за какво отговаря по време на отказ

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

Общи антимодели, които трябва да се избягват

Нека набързо изброим някои "не", които се появяват твърде често:

• Един голям акаунт за всичко: използвайте AWS Organizations. Разделете Prod, Dev, Staging и т.н.

• Оставяне на VPC по подразбиране и групите за сигурност недокоснати: заключете ги.

• Прекалено разчитане на инстанции t2.micro "за тестване" - в крайна сметка те ще се окажат в prod.

• Небюджетиране на разходите за CloudWatch: да, регистрирането струва пари. Нерегистрирането струва повече.

• Даване на достъп до "просто го поправете бързо": вместо това поправете процеса си.

Заключителни думи? Останете гъвкави, останете здрави

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

Никога не сте напълно "готови" - и това е нормално. Важното е да сте целенасочени. Да задавате трудни въпроси на ранен етап. Често провеждане на одити. Автоматизиране там, където е важно. И да знаете кога да потърсите помощ.

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

А за това си струва да се работи.