Ако управлението на сигурността при множество облачни доставчици не беше достатъчно трудно, всеки от тях се проваля по различен начин. За „Индекса за облачна сигурност за 2026 г.“ Intruder анализира данни за грешни настройки от 3000 организации в AWS, Azure и Google Cloud и установи, че профилите на риска при различните доставчици няма почти нищо общо помежду си. Ето как изглеждат данните.
Как се различава рискът при различните облачни доставчици
Intruder групира всяка грешна настройка в една от шест категории: слабо управление на идентичността и достъпа (IAM), липсващо регистриране на събития (logging), грешно конфигурирани услуги, разрешаващи твърде много достъп защитни стени, експонирани услуги и слаба шифровка. За всяка категория те съпоставиха колко профила имат поне един проблем при трите доставчика.
Слабите IAM контроли и липсващото регистриране на събития са почти универсални, засягащи между 80% и 98% от профилите, независимо от доставчика. Останалите четири категории са мястото, където нещата се разминават:
- Експонирани услуги: AWS (76%), Azure (64%), Google Cloud (8%)
- Разрешаващи защитни стени: AWS (83%), Azure (45%), Google Cloud (34%)
- Слаба шифровка: AWS (49%), Azure (35%), Google Cloud (8%)
- Грешно конфигурирани услуги: AWS (68%), Azure (80%), Google Cloud (37%)
Най-голямата разлика е при експонираните услуги – 76% в AWS срещу 8% в Google Cloud. Разрешаващите защитни стени и слабата шифровка следват същия модел, като AWS е с най-висок процент, а Google Cloud – с най-нисък. Грешно конфигурираните услуги са изключение от този модел: Azure води с 80%, а Google Cloud е най-нисък с 37%.
Едно от обясненията защо AWS води по разпространение в пет от шестте категории е, че той е най-големият доставчик по брой предлагани услуги. Повече услуги означават повече опции за конфигуриране и повече възможности за грешни настройки.
Google Cloud има най-ниско разпространение на проблеми в пет категории – той също така предлага най-малко услуги. По-ниското разпространение може да се обясни и с различния подход към споделената отговорност, с модела „Споделена съдба“ (Shared Fate), който предоставя по-сигурни настройки по подразбиране – особено по отношение на мрежовата експозиция и шифроването.
Ето как изглеждат тези категории като конкретни грешни настройки на всяка платформа.
AWS: защитни стени и шифроване
Къде профилите в AWS допускат грешки най-често:
- S3 не налага HTTPS — 87%
- Разрешаващ входящ трафик към чувствителни портове (чрез ACL) — 84%
- Прекалено разрешаващ мрежов ACL — 83%
- Политиката за IAM позволява ескалация на привилегии — 83%
- VPC Endpoint не е активиран за EC2 — 82%
S3 контейнерите (buckets), които не налагат HTTPS, са проблемът, който засяга най-много AWS профили. S3 е една от най-широко използваните услуги за облачно съхранение и въпреки че атаките от тип „човек по средата“ (man-in-the-middle) срещу нея са редки, няма голяма причина обикновеният HTTP протокол да остава достъпен.
Политиките за IAM, които позволяват ескалация на привилегии, засягат 83% от профилите. AWS IAM е известно със своята сложност и управлявана политика, която изглежда сигурна, все пак може да предостави по-широки разрешения от предвидените. При един скорошен incident атаката е ескалирала от компрометирани идентификационни данни до администраторски привилегии за по-малко от 10 минути, компрометирайки 19 AWS субекта (principals).
Azure: съхранение на данни и идентичност
Най-честите грешни настройки в Azure профилите:
- Ротацията на ключове за профила за съхранение не е активирана — 67%
- Ключовете за достъп до профила за съхранение са активирани — 66%
- Публичният мрежов достъп до профила за съхранение е активиран — 61%
- Потребител в Entra без MFA — 55%
- Trusted Launch не е активиран — 45%
Трите основни проблема са свързани с профилите за съхранение в Azure (Azure Storage Accounts), които често съдържат чувствителни данни като лична информация (PII). И трите засягат подобен дял от профили, което подсказва, че където профилите за съхранение не са защитени, обикновено липсват няколко контроли едновременно.
Повече от половината профили имат и потребители в Entra ID без многофакторна автентификация (MFA). Това си струва да се отбележи, тъй като Entra ID управлява достъпа извън облачните ресурси – той покрива Microsoft 365, SaaS приложения на трети страни и локални системи. Пробивът в собствената мрежа на Microsoft от страна на Midnight Blizzard през 2024 г. започна с атака с пръскане на пароли (password spray) срещу стар тестови профил без MFA.
Google Cloud: IAM
Почти всеки основен проблем в Google Cloud се свежда до управление на идентичността и достъпа:
- OS Login MFA не е активиран — 77%
- OS Login не е активиран — 76%
- Неизползван сервизен профил (Service Account) — 75%
- Прекалено разрешаващ сервизен профил — 53%
- Разрешаващ входящ трафик към чувствителни портове — 34%
Повече от три четвърти от профилите нямат контроли за OS Login, които осигуряват по-сигурна алтернатива на традиционния SSH.
Как размерът на организацията променя картината
За повечето категории разпространението на проблеми намалява с нарастването на организациите. За по-големите предприятия е по-малко вероятно да имат разрешаващи защитни стени, експонирани услуги или слаба шифровка.
Изключението е IAM. Слабите IAM контроли засягат 87% от малките и средните предприятия (под 250 служители), 95% от средните компании (251–10 хил. служители) и 98% от големите предприятия (10 хил.-100 хил.+ служители). Това е от съществено значение, тъй като една-единствена идентичност с прекалено много привилегии често е всичко, което е необходимо, за да се заобиколят контроли, които са били засилени на други места.
На средноголемите организации също така им отнема най-много време да отстранят облачните проблеми – средно 35 дни, в сравнение с 8-16 дни за по-малките бизнеси и 10 дни за големите предприятия. Това подсказва, че екипите в средния сегмент управляват сложност на облачната инфраструктура от корпоративно ниво, без да разполагат със съответните специализирани ресурси.
Какво означава това за екипите по сигурност
За екипите, управляващи множество доставчици, трудното е да разберат кои рискове са най-важни за цялата инфраструктура, така че ограничените ресурси и време да отидат на правилните места. Екипите по сигурност се нуждаят от последователен начин за оценка на състоянието при различните доставчици, като същевременно запазват детайлите за конкретната платформа, необходими за действителното отстраняване на проблемите.
Пълният доклад, включително 10-те най-чести грешни настройки за всяка платформа и състоянието на облачната сигурност според размера на организацията, е налице в „Индекса за облачна сигурност за 2026 г.“ на Intruder.