Handouts of ISACA Kyiv event, 05.11.2019, "How works cloud services, which we use". Presentation incudes: - basics of cloud services in current context, - risks of cloud services orchestration from cloud auditor, - references to sources, were best practices of cloud use can be found.

1. Як працюють хмарні послуги
ЯКИМИ МИ КОРИСТУЄМОСЯ
1

2. • Ірині Івченко – за участь, підтримку і обговорення в дослідженні
хмарних послуг
• Глібу Пахаренко – за готовність поділитися досвідом аудитора
хмарних послуг
• Агентству перекладів Task Force Translation – за підтримку в
тестуванні хмарного сервісу для перекладу таксономії
• Олексію Барановському, CyberDn0 та Академії PWC– за допомогу в
організації заходу
Подяка
• Окремі комерційні суб'єкти, обладнання або матеріали можуть бути
згадані з метою адекватного опису експериментальної процедури
або концепції. Така згадка не має на увазі рекомендацію або
схвалення, а також не має на увазі, що суб'єкти, матеріали або
обладнання є найкращими у своєму класі.
Зауваження
2

3. Навіщо цей захід
• Систематизувати обізнаність про модну тему «хмара»
• Усвідомити складність та значну кількість деталей в
підґрунті хмарних послуг
• Звернути увагу на інформацію, потрібну для безпечного та
ефективного використання хмар
• Дізнатися/впорядкувати джерела професійних рекомендацій
щодо використання хмар
3

4. Хмари в приватному житті, приклади
Пошта та поштові
сервіси: gmail,
ukr.net etc.
Файлообмінники та
сховища, як
Google drive
Резервування
смартфонів:
Android, iOS,
Vendor UI
Більшість
мобільних додатків
(мапи, спорт,
здоров’я, ігри…)
Роботи-пилососи
та інші «розумні»
речі
тощо
4

5. Інтернет
"держава в смартфоні“
eID
Біометрія
КЕП блокчейн
хмари
великі
дані
машинне
навчання
АІ
“розумні” речі,
будинки, міста
5G IoT
[Кібер]безпекаОбізнаність
та освіта
Україна, 2019, технологічний контекст, рівень прийняття рішень
Р
о
б
о
т
и
5

6. Світ, хмари, технологічний ландшафт, рівень технічних рішень
https://landscape.cncf.io/ 6

7. Що таке хмарні послуги
• Хмарні обчислення - це модель, що дозволяє забезпечити
повсюдний, зручний мережевий доступ до загального пулу
конфігурованих обчислювальних ресурсів (наприклад, мереж,
серверів, сховищ, прикладних програм і послуг), які можна швидко
забезпечити і звільнити з мінімальними зусиллями з управління або
взаємодією з постачальником послуг.
• Хмарна послуга – послуга з хмарних обчислень – взаємодія
суб’єктів, які беруть участь у транзакції або процесі та/або виконують
завдання у хмарних обчисленнях
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
7

8. Суб’єкти хмарних послуг
• Особа або організація, яка підтримує ділові відносини та використовує послуги
Постачальників хмарних послуг.
Споживач
хмарних послуг
• Особа, організація або суб'єкт, відповідальний за доступність послуг для
зацікавлених сторін.
Постачальник
хмарних послуг
• Сторона, яка може проводити незалежну оцінку хмарних послуг, операцій
інформаційної системи, продуктивності та безпеки впровадження хмарних
послуг.
Аудитор
хмарних послуг
• Суб'єкт, який керує використанням, продуктивністю і доставкою хмарних послуг, а
також веде переговори про відносини між постачальниками хмарних послуг та
споживачами хмарних послуг.
Наприклад: https://www.gartner.com/reviews/market/cloud-access-security-brokers
Брокер
хмарних послуг
• Посередник, який надає можливість підключення та передавання хмарних
сервісів між постачальниками хмарних послуг та споживачами хмарних послуг.
Передавач
хмарних послуг
8

9. Класифікація хмарних послуг
Затипомрозгортання
•Публічна
•Кооперативна
• Локальна
• В аутсорсингу
•Приватна
• Локальна
• В аутсорсингу
•Гібридна
Зарівнемпослуг
•IaaS
•PaaS
•SaaS
Затипомпослуг
• Постачання хмари
• Розгортання послуг
• Налаштування
(оркестрація) хмари
• Арбітраж послуг
• Агрегація послуг
• Інтермедіація послуг
• Аудит
• Безпеки
• Впливу на приватність
• Продуктивності
9
В одного постачальника:
https://cloud.google.com/pricing/list

10. Визначення деяких типів послуг
• брокер-посередник надає послугу, яка прямо покращує певну послугу, надану одному або
декільком споживачам послуг, суттєво додаючи цінності до певної послуги для посилення
певної можливості. (Джерело: Gartner)
Інтермедіація послуги
(Service
Intermediation)
• послуга агрегації брокерських послуг об'єднує декілька послуг в одну або кілька нових послуг.
Це забезпечує моделювання та інтеграцію даних для всіх компонентних послуг, а також рух і
безпеку даних між споживачем послуг і кількома провайдерами. (Джерело: Gartner)
Агрегація послуг
(Service Aggregation)
• арбітраж хмарних послуг подібний до агрегації хмарних послуг. Різниця між ними полягає в
тому, що агреговані послуги не є фіксованими. Тоді як мета арбітражу полягає у забезпеченні
гнучкості та ситуаційного вибору для агрегатора послуг, наприклад, забезпеченні різних
поштових сервісів через одного постачальника або сервісу кредитного скоринга, який
перевіряє декілька скорингових агентств та обирає найкращий результат. (Джерело: Gartner)
Арбітраж послуг
(Service Arbitrage)
10
Джерело: NIST Special Publication 500-292
Приклади подібних послуг: https://www.gartner.com/reviews/market/cloud-management-platforms

11. Постачальник хмарних послуг
Безпека
Приватність
Споживач
хмарних
послуг
Аудитор
хмарних
послуг
Брокер
хмарних
послуг
Передавач хмарних послуг
Брокер
хмарних
послуг
Підтримка бізнесу
Постачання/
налаштування
Переміщуваність/
інтероперабельність
Інтермедіація
послуг
Агрегація
послуг
Арбітраж
послуг
Аудит безпеки
Аудит впливу
на приватність
Аудит
продуктивності
Налаштування хмарних послуг
Рівень послуг
Рівень абстракції ресурсів та
управління
Рівень фізичних ресурсів
Апаратне забезпечення
Приміщення
IaaS
PaaS
SaaS
Як
користуватися
Розкласти за
моделлю умови
контрактів:
• Визначити
суб’єктів
• Визначити межі
впливу
Сформувати
контролі та
відповідальність
за моніторинг
Принципова еталонна модель - NIST SP 500-292, рис.1
11

12. Розподіл відповідальності
Джерело: NIST Special Publication 500-299 (draft)
Як
користуватися:
Визначте
контрагентів
Перевірте
умови
контрактів
Налаштуйте
моніторинг
12

13. Ми йдемо в хмару. Як це?
НА ЩО ЗВЕРНУТИ УВАГУ
13

14. Приватний користувач
Розумійте, що ваші дані в публічних хмарах доступні не лише вам,
кому - читайте privacy policies
Налаштуйте приватність за всіма обліковими записами, особливо,
якщо через них логін ще десь (як Gmail чи FB)
Перевіряйте доступи на інформацію, яку розшарюєте
На смартфоні перевірте та налаштуйте дозволи додатків
Справді конфіденційне – відсутнє на електронних носіях
14

15. • тип
розгортання
• тип послуг
• рівень послуг
Мінімум
(малим)
• Мінімум
• стек
технологій
• результати
оцінки ризиків,
включаючи
компетенції
• ROI проекта
Максимум
(великим
чи
критичним)
NB: Для прийняття рішення про використання
хмар в організації потрібно знати одночасно
15

16. Приклад
«ми
йдемо в
хмару 1»
Хмарний додаток (SaaS), розгорнутий в
публічній хмарі, за договором з
брокером
«ми
йдемо в
хмару 2»
інфраструктура (ІaaS), розгорнута в
приватній локальній хмарі, за договором
з внутрішнім постачальником
Різні
компетенції
в замовника
Різні
можливості
контрактора
Різні ризики
VS
16

17. Що ви контролюєте в хмарах
Cloud platform
AWS/GCP/Azure
G-suite
Office 365
Slack,
Viber, etc.
Deployed app
[Outsourced]
Data
center
Docker
Kubernetes
Споживач котролює
Третя особа контролює
Cloud deployed
17

18. Що завжди на стороні споживача
• Secure Cloud Consumption Management
• Secure provisioning and configuration requirements
• Secure Portability/Interoperability requirements
• Secure Business Support requirements
• Secure Organizational Support (including organization processes,
policies and procedures).
• Secure Cloud Ecosystem Orchestration - найпоширеніші на
практиці ризики розповідає Гліб Пахаренко
Джерело: NIST Special Publication 500-299, 4.2 (draft) 18

19. Cloud orchestration risks
Glib Pakharenko

20. Cloud orechstration stack

21. Cloud services (TOP layer)

22. Cloud services (TOP layer)

23. Kubernetes architecture

24. Kubernetes architecture

25. Risk #1: Compromise in the cloud
A compromise to the degree described earlier is effectively
irreparable, and the standard advice to "flatten and rebuild" every
compromised system is simply not feasible or even possible if
Active Directory has been compromised or destroyed.
© https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/planning-for-compromise
Recovery from a full compromise is extremely difficult requiring
vast amounts of time. A likely scenario is that a victim may need
to rebuild the domain from scratch.
© https://securelink.net/insights/pentesting-stories-errors-limited-hygiene/

26. How to quickly rebuild infrastructure?
• manual deployment guides xx pages long are not feasible
• deployment automation even for small deployments:
• Ansible/Chef/Puppet for nodes
• Terraform for kubernetes deployments
• Helm for applications deployments
• CI/CD tools for deployments
• managed services for quick setup (e.g. cloud database engine
instead of database on IaaS)
Risk #1: Compromise in the cloud

27. How to do IR in the cloud?
• dedicated cloud account and infrastructure for security
• logs collection and monitoring
• containers compromise monitoring (who runs a shell there?)
• cloud objects logs
• kubernetes objects logs
• netflow/sflow collection and monitoring
• compliance monitoring (e.g. forseti)
• monitor budget spendings (e.g. someone mines cryptocurrency
on your infrastructure)
Risk #1: Compromise in the cloud

28. How to manage access in the cloud? Consider that to
have a good assurance about access revocation you
need to redeploy the assets!
© https://cloud.google.com/security/data-loss-prevention/revoking-user-access
If you're concerned about the code integrity of your
deployed apps, you may want to redeploy them
(including any modules) with a known-good checkout
from your version control system.
Risk #1: Compromise in the cloud

29. How to manage access in the cloud?
© https://cloud.google.com/security/compromised-credentials
• Replace Service Account Private Keys (JSON and p12 files)
• Regenerate API Keys
• Reset OAuth2 Client ID Secrets
• Remove Google Cloud SDK Credentials
• Remove ssh keys from VMs
• Revoke access to cloud SQL databases
• Invalidate Browser Cookies
• Delete all unauthorized resources
• And many other cloud and kubernetes potential backdoors could exist
Risk #1: Compromise in the cloud

30. Risk #2: Issues with governance in the cloud
Consider the following issues with access management and
resource provisioning:
1.Access management:
a. Admins in the cloud objects.
b. Admins in the Kubernetes objects.
c. Admins in the applications and docker images (hardcoded credentials).
2.Kubernetes has more than hundred type of objects:
a. How to authorize creation of new K8 objects?
b. How to authorize creation of new docker images?
c. How to authorize creation of new cloud objects (e.g. storage buckets)?

31. Key DevOps problem:
1.Old paradigm: InfoSec mandates through policy -> IT
implements no longer works.
2.InfoSec -> transforms into -> DevSecOps:
a. DevSecOps implements a one-click solution and IT just deploys that
(through Terraform/Helm/CI etc.)
3.More responsibility comes to DevSecOps:
a. If %CPU is overloaded due to the improper rules for web-firewall?
b. If a proper workaround for the security bug (CVE) exists instead of
updating the software?
c. DevSecOps should follow the Technology policy (say Mongodb is
banned, and we need to use Azure Cassandra).
Risk #2: Issues with governance in the cloud

32. Risk #3: Issues with segregation
The segregation should be implemented on many tires:
1.Consider the scenario for crypto-currency exchange. If we run the
different blockchain nodes (BTC/LTC/Monero) in the same cluster than
we’re very vulnerable if one is compromised.
2.Implement Pod<->Pod network level filtering (and encryption if possible).
3.Implement message queue security between microservices (in many
deployments only access to the BUS is authorized).
4.Limit access from Pods to the Cloud service accounts (and consider the
risk of SSRF bugs!).
5.Do not use shared secrets (say for Oauth2).
6.Limit commits ability to the main branch (e.g. only few seniors can handle
pull requests).
7.Separate Prod/Test/Dev clusters and all cloud accounts.

33. Other important points
1.Do not hardcode credentials in any way. Use kubernetes secrets at least.
2.Watch for vulnerabilities in all infrastructure layers:
a. Docker images (e.g. if there was no rebuild for 1 year image how many vulns are
there).
b. Cloud.
c. K8
d. etc.
3.Implement hardening on all levels (Application/OS/Docker/K8/..)
4.The lack of knowledge about modern clouds inside teams leads to the
security nightmare
5.Use signed Docker images and sign code and packages.
6.Use technology specific tools for compliance (e.g. K8 admission
controllers, or WP core::integrity checking).

34. Other important points
7.Manual operations lead to mistake (e.g. publish service on the
external IP -> implement firewall).
8.High speed of development leads to the lack of documentation
(e.g. even all software requirements are in the Jira tickets). If
you do not have an order now then you won’t have it in the
cloud either.
9.Just copy->cloud of the enterprise infrastructure is costly and
often ineffective. You need ot shift to the cloud paradigm of all
development&deployment process.
10.It is very very hard to move monolithic application to the K8
and cloud microservices.

35. Джерела
35

36. Джерела, з чого починати:
Наш переклад українською таксономії хмарних послуг:
• https://www.slideshare.net/AnastasiiaKonoplova/nist-cloud-computing-taxonomy-ua-translation-by-isaca-kyiv
Російською, шлях у хмари:
• https://habr.com/ru/company/flant/blog/350928/
Проект безпечної архітектури хмарних послуг від NIST:
• https://collaborate.nist.gov/twiki-cloud-
computing/pub/CloudComputing/CloudSecurity/NIST_Security_Reference_Architecture_2013.05.15_v1.0.pdf
36

37. Де шукати
кращі
практики
про хмари
• ISACA
• http://www.isaca.org/Knowledge-Center/Research/Pages/Cloud.aspx
• NIST
• https://csrc.nist.gov/search?keywords=cloud&ipp=50
&sortBy=relevance&showOnly=publications%2Cpresentations&
topicsMatch=ANY&status=Final%2CDraft&series=
FIPS%2CSP%2CNISTIR
• CSA (Cloud security alliance)
• https://cloudsecurityalliance.org/research/artifacts/
Високорівневі організаційні
• NIST
• CNCF (Cloud Native Computing Foundation)
• https://www.cncf.io/
Високорівневі технічні
• Технічна документація та навчання постачальників,
наприклад:
• MS AZURE https://docs.microsoft.com/ru-ru/learn/azure/
• AWS https://docs.aws.amazon.com/index.html
• GCP https://cloud.google.com/docs/
Детальні технічні
37

38. Приєднуйтесь!
Анастасія Конопльова
Наші новини та події:
https://www.facebook.com/Kyiv.ISACA/
Більше інформації:
https://isaca.org/
CISA
Президент ISACA Kyiv
LLC UAG
a.konopleva@isaca.org.ua
+38(050)9570596
38
Гліб Пахаренко
CISA, CISSP, OSCP
PakurITy
gp [at] pakurity.com
http://pakurity.com
https://www.linkedin.com/in/gpaharenko/