Привіт! Вітаю тебе на цій сесії про безпеку без серверних технологій та всі легенди та міфи, які існують в цій темі. Мене звати Наталя Годик, я харків'янка, живу в Лондоні вже багато років. Я системщик, DevOps, Cloud-архітектор, Cloud-інженер і всі інші назви цієї професії, які трендові, звичайні. Останні шість місяців змінюється весь час. Останнім часом я працюю саме архітектором хмарних технологій в компанії Zencore. Я також GDE в Cloud Platform. GDE – це мережа лідерів думок, яку спонсорує Google. Вони існують в різних технологіях, і моя технологія – це, звісно, Google Cloud. І ви можете знайти мене в усіх соцмережах, які існують. Ні, не всіх, не в Facebook. За тигром увесь світ. Я також фотограф, тому приєднайтесь, і будемо спілкуватися і ділитися враженнями.

Це приклад посвідчення водія в австралійському штаті Вікторія. А це електронний лист, який уряд штату Вірджинія надіслав своїм резидентам, повідомляючи їх про те, що після хаку місцевої компанії Optus, після Data Breach, їм доведеться випустити нові посвідчення водія для мільйона своїх жителів. Що це таке? В штаті Вірджинія всього декілька мільйонів жителів, і цілий мільйон із них має отримати нові посвідчення водія тільки через те, що компанію Optus хакнули. Як це відбулося? Мабуть, якась серйозна, можливо, державна спонсорована терористична хакерська група зламала цю компанію Optus? API. Просто API, просто ендпоінт в інтернеті. І ось на цьому скріншоті журналіст Джеремі Карк написав, що він розмовляв з хакерами, тими, хто стоїть за цим Data Breach, і що вони просто зайшли на цей API і скачали дані користувачів. What? Так, ніякої автентифікації на цьому API не було. Просто зайшли, просто скачали дані десяти мільйонів австралійців. Населення Австралії, всієї Австралії 25 мільйонів, і 10 мільйонів з них були користувачами компанії Optus. І їхні дані просто скачали з API, яке було залишено в відкритому доступі. Мабуть, хтось подумав, ну, я просто експериментую. Воно ні до чого не приєднано. Залишу там. І забули. І не поставили туди ніякої автентифікації.

А це в Twitter. І люди жартують, що, значить, компанія Optus не була жертвою хаку і хакерів. Вони просто виклали дані користувачів в інтернет. Як вам таке? За цими двома QR-кодами ви можете прочитати таймлайн цього Data Breach. І також твіт. Треба прочитати в Twitter. Всі ми знаємо, що він більше не Twitter, але. Треба журналіста Джеремі Кьорка про цей Data Breach. 10 мільйонів людей із 25 мільйонів. Уявіть собі, це більше третини населення. І їхні дані були просто скачані людиною, яка шукала собі API. І шукала собі, чи є якісь там дані поза цією API-адресою. Яка була залишена в відкритому доступі. Сьогодні ми говоримо про без серверні технології. Ми не знаємо, яка технологія стояла за цим API компанії Optus в Австралії.

Але можна собі дуже легко уявити, що такі ситуації відбуваються, коли ми швиденько хочемо щось зробити, швиденько запустити свій таск в хмарі. Використати найлегшу технологію, яка існує для нашого використання. І це дуже часто без серверні технології. Тобто технології, які попадають під цю категорію. І що ми робимо? Ми просто запускаємо свій таск і не думаємо про те, як налаштувати правильно цей таск. Всілякі ваші лямбди, всілякі ваші Fargate, ECS, Cloud Run, Cloud Functions. Все це дуже легко використовувати, але дуже легко залишити відкритим. Давайте зробимо крок назад. І обговоримо, про які саме технології ми говоримо, коли говоримо про безсерверні. Зазвичай мова йде про Compute. Тобто те, в чому можна запустити якийсь таск або якийсь контейнер. Я використовуватиму приклади AWS та GCP в цій презентації, тому що ці хмари для мене найбільш знайомі. Також ми порівнюємо лямбди з Cloud Functions. Це схожі технології, а Fargate і Cloud Run це не дуже схожі технології.

І ви побачите, що згодом у слайдах ми будемо іноді порівнювати яблука з апельсинами. Але більш-менш говоримо про одну й ту саму тему. Тобто, що у нас є Serverless Compute? І про те, про що ми частіше за все говоримо, коли говоримо про Serverless. Це лямбда або функції. Щось, якийсь код, бім-бам-бум, ми запустили в хмарі, він там щось робить, реагуючи на якусь подію. Або це просто контейнер. Fargate в AWS, Cloud Run в Google. Взяли контейнер, кинули в хмару, він там запустився десь. Ми не думаємо про те, що ним контролює, не думаємо про мережі, не думаємо, де він запустився. Все, про що ми думаємо, це те, що у мене є мій контейнер, і воно там крутиться.

Але Serverless це не тільки Compute. Існують також бази даних безсерверні. Наприклад, Aurora та LODV. Це для SQL, реляційних баз даних. Або DynamoDB та Bigtable для NoSQL баз даних. І є інші, це тільки приклади. Тобто це бази даних, в яких ви не бачите самої віртуальної машини, на якій ця база даних крутиться. Ви не маєте жодного інстансу, у нього немає жодної IP-адреси. Ви не керуєте мережами. І ми можемо йти навіть далі в цій темі. Serverless Data. Це всілякі спеціальні функціоналі, спеціальні продукти, які хмарні провайдери створюють для вирішення якихось конкретних задач. І зазвичай ми користуємося цими продуктами, коли хочемо щось конкретне зробити і не хочемо задумуватися, як це реалізувати.

Наприклад, у нас є Queues і Topics. Тобто стрімінг якихось даних, стрімінг пакетів даних. Або повідомлень. Це SQS та PubSum, AWS, DCP еквіваленти відповідно. Ми можемо використовувати Kafka, наприклад, для цього. Або RabbitMQ саме для черг повідомлень. Але є без серверні технології від хмарних провайдерів, які ми можемо просто клік-клак, done. Так? Під'єдналися, читали, записали, все чудово. Всім відомі S3 та Storage Buckets. Це також без серверні технології. Тому що ми не бачимо мережі, ми не бачимо віртуальної машини, інстансу, на якому цей Storage існує. Але ми можемо зберігати там терабайти і петабайти даних. Тобто десь цей сервер існує, але ми про нього нічого не знаємо і не хвилюємось про нього.

Сьогодні ми будемо говорити в основному про Compute. У мене є інші думки і теми щодо Data Platforms і Data Products. Але сьогодні ми сфокусуємося саме на Compute. Всі ці технології, вони дуже кльові тим, що вони дають девелоперам, специфічним девелоперам, можливість дуже швидко щось виробляти, дуже швидко щось деплоїти. Не замислюючись над тим, які системи стоять під капотом, не замислюючись над тим, як це все організовувати, конфігурувати, як воно працює, як будуть налаштовані мережі, а як мені приєднатись до інтернету, а як мені приєднатись до S3-бакету, а куди підуть пакети, а чи є у мене DNS. Ні, про це не треба думати. Ми просто написали код, запустили, або в випадку з базами даних та Data Products, просто залили дані кудись там, подумали про те, що можливо воно там, ну не знаю, на мінімумі, хто має доступ до цього бакета або до цієї бази даних.

Все, готово. Дуже легко використовувати. Але також дуже легко забути і не думати про те, як це захищати. І через те, що у цих продуктів порівняно з традиційними системами і традиційними продуктами, тобто коли ми говоримо про традиційні системи і їх захист, і їх безпеку, ми зазвичай говоримо у більшості про захист мереж, які порти відкриті, які у нас є Security Groups або Firewalls, або що. То коли ми говоримо про без серверні технології, мережі у нас як такової немає. Є нюанси, ми про це поговоримо, але як такової мережі немає, яка під нашим контролем би була. Цей інстанс, цей контейнер, ця функція, ця база даних, вона десь там. В якійсь мережі, звісно, але не у нас і ми про це не хвилюємось.

Тому у нас є інші складові захисту цих без серверних технологій. Це у нас хто має доступ до цього сервісу, хто може запустити цю функцію, хто може запустити цей контейнер, хто може активувати API. У нас є внутрішні механізми безпеки, що у нас вбудовано, якщо ми говоримо про Compute, якщо ми говоримо про контейнери, функції і так далі. То що у нас всередині коду, що ми написали, яка там є можлива перевірка сертифікатів або авторизації або що. І третє, це до чого має доступ цей сервіс. Тому що це у нас хмарні технології, все з усім дуже класно інтегрується і все до всього має доступ. До чого має доступ цей сервіс, про який ми говоримо, який ми намагаємося захистити, це теж складова захисту без серверних технологій.

І почнемо ми говорити саме з однієї точки зору, з точки зору хто куди має доступ. І почнемо ми говорити саме з однієї точки зору, з точки зору хто куди має доступ. І один із міфів, які існують в хмарних технологіях і без серверних частіше за все, це то, то ми просто експериментували, воно ні до чого не приєднано. Так мабуть думали девелопери того API австралійської компанії Optus, які залишили без автентифікації, без авторизації API, який має доступ до всіх 10 мільйонів їхніх клієнтів. І їхньої документації і інформації. І їхньої документації і інформації, персональної інформації. Вони мабуть думали, та та, он, нічого не приєднано, не треба про це думати вигалі.

Розглянемо приклади Cloud Run і Lambda, це от ми порівняно, порівнюємо яблуки, ну можливо не earrings, а з грушами функції, з контейнерами. До чого має доступ наш сервіс? Марі, і він, наприклад, буде считувати у нас повідомлення з одного PubSub topic, з одного топіка, писати події в меседжі в інший топік, можливо, читати і писати дані в якихось базі даних, і також писати логі. Оці всі топіки, бази даних, бакети, логі – це те, до чого має доступ цей сервіс. Так само з лямбдою. Лямбда може запускатися, читаючи меседжі з одного SQS queue, чи в черги називаються, писати, щось там трансформувати, писати ці меседжі в інший queue, читувати та записувати дані в якусь базу даних, і писати логі.

Якщо ми говоримо, що ми запустимо просто там щось там в хмарі, ми просто експериментуємо, ми ні про що не думаємо, часто легше за все використовувати якісь дефолтні конфігурації, які є в хмарному провайдері. В Гуглі це дефолт сервіс аккаунт. В Гуглі є такий концепт сервіс аккаунт, це якби користувач, але не людина, а робот. І от всі процеси, які крутяться в Гуглі, вони крутяться, маючи identity, саме сервіс аккаунт. І існують дефолтові сервіс аккаунти, які створює Гугл в ваших проєктах, проєкт – це як AWS аккаунт, це якби ваша сфера діяльності. І декілька цих сервіс аккаунтс створені по дефолту, і вони будуть використані по дефолту за замовченням вашими сервісами. Наприклад, є Compute Service Account, він дуже відомий, такий сервіс аккаунт, тому що він має editor роль на рівні проєкту. Тобто він може читати і практикувати всі ресурси в цьому проєкті. І якщо не думати про це і залишити цей сервіс аккаунт за замовченням, то ваш сервіс Cloud Run, він використовуватиме цей сервіс аккаунт, і він матиме Read-Write доступ до всього проєкту. Тобто, наприклад, якщо у вас є продакшн проєкт в якому-небудь регіоні, наприклад, ви так зробили сепарацію ресурсів на рівні енварімента та регіону.

І, наприклад, у вас в цьому проєкті є і Cloud Run сервіси, і Big Query Data Sets, тобто всі ваші дані, дані користувачів, аналітика, все це відбувається в цьому проєкті також. Логі, звісно, і PubSub для обміну інформації для стрімінгу даних. І от ви запускаєте Cloud Run Service, якусь апку, якийсь контейнер, використовуючи дефолтовий сервіс аккаунт, він буде зараз мати доступ до всіх ваших данів, до всього, що є в Big Query, до всього, що є в Storage Buckets. Матиме доступ їх читувати і писати, модифікувати. Єй! Not great! Як це виправляти? Треба створювати спеціальні Service Accounts, краще за все їх створювати для кожного сервісу, тобто для кожного контейнеру, який ви запускаєте, для кожної апки, і давати List Privileged роль для цього аккаунта. Як ми це робимо, як ми це приєднуємо, тоді цей сервіс матиме доступ лише до того, до чого він має, що йому потрібно. Тобто всі ваші дані в Big Query він вже не зможе читувати, записувати, він зможе тільки робити те, що ви сказали і конкретно на яких ресурсах.

Також по темі IAM і доступів, і access-ів, нічний жах всіх security operations people, це статичні токени. Статичні токени це такі ключі до вашої інфраструктури, які дуже легко створити і почати використовувати. І дуже легко вкрасти. Якщо зараз погуглити Lambda vulnerabilities та почитати останні дослідження щодо того, що роблять хакери, які vulnerabilities використовують і експлойтять саме в Lambda, то ми побачимо, що єдиний спосіб Lambda саме хакнути і туди якийсь спеціальний malicious код додати. Це вкравши IAM security, user and secret keys. Тому це така штука, яку часто всілякі pipeline, для всіляких pipeline ми використовуємо ці ключі.

Часто для всіляких third party tools, якийсь амоніторинг у нас, якусь штуку ми хочемо прикрутити до свого клауда і ми тоді просто створюємо ці ключі, загрожаємо їх в цю третьу систему і живемо щасливо, ніколи не замінюючи ці ключі. Google сам каже таку штуку, що too bad actors service account keys can be more valuable than a leaked password. Що це означає? Це означає, що паролі користувачів менш корисні для хакерів, ніж ці ключі. Причина дуже проста, тому що, як я сказала, ми дуже часто ці ключі створюємо для всіляких pipeline, автоматизації і так далі. Тобто для service account чи юзерів, у яких super elevated privileges. Тобто це наші root access, це наші моніторинги, це наша автоматизація, роботизація. Тому, звісно, якщо вкрасти такий service account, то хакер має доступ до значно більшої і ширшої кількості дій, ніж якщо зламає пароль якого-небудь парубка з маркетингу, так? Скажімо. Чому це все важливо? Давайте подивимось на невеличке демо.

У нас є така апка, такий інтерфейс. Давайте уявимо, що ми хакери, ми знайшли цей API, такий як той хакер, який знайшов API австралійського Optus. Що ми бачимо? Ми бачимо, що це run, в адресі ми бачимо run.app, тобто це Cloud Run утиліта. Тобто Google Cloud. BigQuery SQL Explorer. BigQuery – це big data утиліта від Google. You have access to two datasets in the drop-down list below. Clients Redacted і Connections. І от нам тут пропонують для того, щоб почати, спробуйте перечислити всі таблиці, які є в цьому датасеті, який ми обрали. Clients Redacted. Давайте спробуємо цю цей запит. У нас є одна таблиця клієнти. Цікаво. А що ще у нас є в цій схемі? А в цій схемі у нас є набагато більше інформації. У нас є, наприклад, факт того, що проект, GCP project називається N-Godex Sandbox. Таблиця у нас, датасет у нас Clients Redacted.

Ок. Дивлячись на це, Clients Redacted, знаючи трошки про те, як люди роблять Data Engineering, то я можу подумати про те, що тут є інші датасети, які, можливо, не Redacted. Тобто, якщо, що буде, якщо я зроблю Select Star from Clients Redacted, from Clients. У нас є табличка Clients. Давайте спробуємо. Її почитати. Ок. У нас тут City, Region, Year of Birth та ID. Щось мені підказує, що є десь датасет Clients Not Redacted. Можливо, у мене є до нього доступ. Як би мені до нього взяти доступ? Я, знаючи, як працює BigQuery, знаю, що у мене є ось такий запит. Я знайшла ім'я проекту, зробивши Select Star from Clients. І я можу прочитати таку ж саму, типу, метадані і того, що існує в цьому проекті загалом. І я все одно, ну, типу, окей, давайте спробуємо, навіть якщо dataset is selected.

Давайте подивимось, чи цей запит на весь, типу, глобальний проект, чи є в ньому якісь інші датасети. Чи є в нас до цього доступ? Ага. У нас є до цього доступ. Клас! Clients Redacted, Clients Raw. Окей! That's more interesting. Давайте подивимось, подивимось, які там є в цьому Clients Raw таблички. У нас сам інтерфейс пропонує такий запит. Я знаю, що якщо я зроблю повний повне ім'я датасету, тобто проект датасет Information Schema, то я можу, можливо, я зможу замінити, підмінити цей датасет, який в цьому дропдауні. Тому що clearly ми бачимо, що цей дропдаун вибирає, з яким датасетом працювати SQL Query. Можливо, я можу це переписати, типу, override that через саму SQL Query.

Давайте подивимось. У нас було Clients Raw ми знайшли. Так, що я не вмію писати. Ага! У нас є табличка Client Data, у нас є до цього датасету доступ. Прикольно! Client Data. І ми хочемо, я хочу прочитати все, що там є. Окей, це вже цікавіше. У нас є доступ до Raw Data, не редагованих даних, ім'я, рік народження, Social Security Number. Тут у нас мікс українських імен та, судячи з усього, французьких. Тобто це у нас буде ідентифікаційний код і французький чи британський Social Security Number. Та навіть адреса. Тобто з ідентифікаційним кодом датою народження, ім'ям і адресою ну це якби все, що ти можеш знати про людину.

Ну, паспортного номеру немає. Звісно, це демо, так? Але! Це у нас показує те, що, якщо не розумітися про те, до чого має доступ наша функція, до чого, які є ролі, за якою адентикою наш контейнер крутиться в хмарі. А також, можливо, це ж явно апка, яку створюють для аналітиків і data scientists. Зазвичай в таких випадках треба якусь автентифікацію туди запилити. Якщо не самій апці, а якби Streamlit, це відома library, яку просто береш і використовуєш. В Google є така штука, як identity-aware-proxy, яку можна запилити і поставити перед контейнером Cloud Run, тобто у вас буде load balancer і identity-aware-proxy, який буде блокувати прямий доступ до адреси DNS streamlitbqueryapp.run.app.

Це дефолтовий DNS, DNS-адреса для кожної апки, яка запускається. Можна доступ до цієї DNS-адреси заблокувати і зробити так, щоб можна було мати доступ лише через load balancer. І давайте якраз на це подивимось. І перед цим до цього load balancer прикрутити identity-aware-proxy для того, щоб тут був логін, щоб люди не могли просто взяти туди зайти. І якби я маю доступ до цього UI, але BigQuery не знає, що це я. Він бачить айдентику саме цього контейнера Cloud Run App. Тобто треба про це теж думати. Якщо ви даєте якийсь доступ до якихось даних, то це whole another level. На іншому рівні треба думати про те, хто до чого має доступ. Тому що якщо ви подумали про те, що ваш юзер має доступ до таблички Clients Redacted, а Cloud Run ваш має доступ до всього, то ну як би всі ваші дані будуть дуже чудово зчитані юзерам, які не мають мати доступ до цих даних.

Щось натякає, це буде просто експеримент, я сказала про те, що доступ до цього дефолтового DNS можна замінювати і не давати доступу прямо туди. Давайте подивимось як. На двох прикладах, Lambda і Cloud Run, знову ж таки. Я сказала про Load Balancer. У Lambda є такі штуки, як Lambda Function URLs. Тобто зазвичай ми що робили? І в Cloud Run, і в UGLI, і в AWS ми пилили якісь gateway перед функцією або перед контейнером. IPI Gateway або Load Balancer with Identity-Aware Proxy чи щось таке. В Lambda це така нещодавна фіча, є просто Lambda Function URL, тобто у вас є просто адреса вперед. Не треба думати про API Gateway. Я думаю, якщо ви порозпитуєте у своїх друзів, чи вони десь мали якийсь Data Leak або якийсь Hack або щось таке з безпекою поєднане саме в Lambda або функціях, хмарних функціях, то найчастіше це те, що вони забули припилити API Gateway і доступ до цієї функції був просто відкритим в інтернеті без всіякої автентифікації, без філяхтінгу.

В Lambda тепер є Lambda Function URL, як і в Cloud Run є їхні URL, які просто будуть в інтернеті. По дефолту ці ці URL вони деплоється з типом автентифікації None. Тобто як я от зараз в цю апку Streamlit BigQuery Explorer зайшла і ніякої автентифікації не було, ніякої авторизації не було. Тобто по дефолту у вас йде це. Зробіть свої ставки, яка кількість девелоперів буде думати, коли вони деплоєть, просто клікопсять в консолі. Lambda скільки з них подумає про те, що це ж мені треба ще автентифікацію допилити. І policy також дуже легко залишити. По дефолту policy у Lambda invoke function URL всі. Authentication type None. Хто завгодно може запустити цю Lambda. Знову ж таки треба думати про те, яка policy, які туди принципи, як буде проводитися автентифікація, авторизація, хто має доступ, хто не має доступ. А іноді і треба, щоб був такий відкритий доступ, тому що це наприклад якісь API, які ви даєте вашим партнерам.

І тоді треба думати про те, як токенами управляти і як робити внутрішню авторизацію всередині Lambda і залишати відкритий доступ. Але ну як би про це треба думати. Так само в Google, те, що я змогла зайти за допомогою просто от цей дефолтовий автоматично створений URL самого сервісу. Ми бачили, це був просто Streamlit BigQuery, або Cloud Run.app, бла-бла-бла. Можна контролювати інгрес. Я говорила про те, що в безсервних технологій немає мережі, але деякі речі можна все-таки контролювати. І одна з них, це в Cloud Run, це інгрес. Тобто ми, наприклад, пилимо Load Balancer з Identity Aware Proxy, допилюємо DNS-адресу на Load Balancer з сертифікатом, з усім. І тепер ми робимо так, щоб люди заходили через Identity Aware Proxy, авторизувалися і використовували цей новий, нову DNS-адресу. А за кулісами це вже Cloud Run, і ніхто не знає про те, що це Cloud Run. По дефолту, інгрес конфігурація, інгрес полісі у Cloud Run, це allow traffic all. Весь трафік дозволений. Тобто, якщо хтось вгадає, брудфорсить, дізнається, десь побачить, десь піддивиться самі цей автоматичний URL самого сервісу, то він зможе обійти всі ваші Identity Aware Proxy і всі ваші Load Balancerи і всі сертифікати. І напряму говорити з сервісом.

Так, як я зробила в демо. Про це теж треба думати і знати, і замінювати на спеціальну конфігурацію. Internal Only. Це тільки з внутрішніх мереж, а Internal Load Balancer, це означає, що трафік, який якщо ви зробите запит на дефолтовий URL, то він буде заблокований, тому що в нас інгрес, що трафік має приходити тільки з Load Balancer. Такі приємні моменти, які по дефолту, якщо ми просто кликопсимо в консолі, то можна навіть не задумуватись і всі навіть конфігурації, які ми подумаємо про Identity Over Proxy, авторизацію і все таке, можна їх обійти, якщо неправильно сконфігурований інгрес.

Давайте тепер подивимось на такі невеликі Quickfire Security. Перше це AWS не шифрує за замовченням ні в спокої, ні в транзиті. Адреса не в транзиті, тому база даних S3 бакет і все-все-все, SQS топіки і так далі, все треба шифрувати. Serverless is not really serverless, тобто у вас є все-таки десь там мережа і іноді нам треба і можна зробити так, щоб ваші функції, Cloud Run і так далі, були в вашій мережі, були в вашій приватній мережі, тому що Cloud Services це публічний API, від цього треба якось захищатися, від цього це треба якось закривати і контролювати, де можна на рівні мереж.

В GCP для того, щоб функції Cloud Run були в середині мережі, ми використовуємо Serverless VPC Connector. Connector це така штука, ну, це окремий ресурс, який ми деплоємо і тоді всі ці безсерверні compute технології будуть начебто в нашій мережі. У них буде IP, приватне IP нашої мережі. В Cloud Run тепер є нативний VPC Igress, тобто нам більше не треба запускати Serverless VPC Connectors в Cloud Run. AWS це VPC Endpoints, знову ж таки це деплоється в VPC-шку і конектиться потім всілякі ваші бакети, функції і DynamoDB, логи і так далі будуть бачитись як приватні інстанси в вашій власне мережі.

Ну і останній, це моя улюблена штука, якою я люблю завершувати такі всілякі презентації про безпеку. Якщо ви б бачили мою презентацію навесні на DevOps конференції, то ви знаєте про що це. Вимкніть, будь ласка, публічний доступ до ваших Storage Buckets. Будь ласка, дякую. Це скріншот з публічно доступного сервісу, який я просто погуглила, гугличі Public AWS Buckets. І ми бачимо 300 тисяч AWS Buckets, 90 тисяч Azure Blob Storage, 106 тисяч Google Buckets. Мають відкритий доступ, і люди туди просто можуть зайти. Тобто без всілякої автентифікації, без всіляких restrictions.

І це невеличке відео того, що можна знайти, це просто тупо в інтернеті, просто в інтернеті є сервіс, яким можна шукати якісь файли, можна дивитися, які файли є в цих бакетах. І ці файли це credentials, це JSON-файли з ключами, це ID RSA, іноді .pub, тобто публічні ключі, а іноді ні, іноді приватні ключі люди залишають в відкритому доступі. SSH ключі, все, що завгодно. Будь ласка, перевірте свої бакети і заблокуйте до них публічний доступ. А ще краще, зробіть організаційну полісію, це organization policy в Google або RBS config, щоб на організаційному рівні заблокувати створення бакетів, які публічно доступні. Дякую за вашу увагу!