Доброго дня, колеги.

Керівництво доросло до розуміння потреб чогось на зразок "OSS for software development".
Зокрема ось хотєлкі (нижче). Вони стосуються в першу чергу нашої AWS-інфраструктури.
Може хтось щось підкаже в цьому плані?
А то по телко я ніби в курсі, а ось по software development та програмних комплексах/системах ні.
Може якісь стандарти/рекомендації напрацьовані/існують у світі для управління цим усім господарством? Ну і готові системи управління...

Ось самі хотєлкі (просто тези, котрі вдалося застенографувати):

---------------
Хотілося б мати завжди актуальну (up to date) інвентаризацію всіх програмних систем у нашому середовищі розробки.

Що потрібно від цієї інвентаризації:
1. Перелік всіх елементів інфраструктури, систем та програмного забезпечення, якими ми користуємося і за які несемо відповідальність
2. Які версії операційних систем та програмного забезпечення працюють на кожній такій системі?
3. Хто несе відповідальність за те, що система правильно налаштована та експлуатується в усіх відношеннях?  Хто "власник" системи?
4. Як здійснюється моніторинг кожної системи?  (Варіанти: ніяк, Intruder, Wuzah, централізоване ведення журналу, локальне ведення журналу тощо)
5. Хто переглядає вихідні моніторингові дані?
6. Як налаштовується кожна система?   (Варіанти: вручну, Terraform, інша автоматизація тощо)
7. Де можна знайти документацію для правильного налаштування кожної системи?
8. Який статус безпеки системи?  (Варіанти: невідомий, сумісний з CIS, сумісний з SOC2 тощо)
9. Хто відповідає за безпеку в системі?
10. Хто має адміністративний доступ до системи?
11. Які зв'язки з іншими системами має дана система?
12. Чи має система зовнішні підключення до Інтернету?
13. Дата останнього перегляду/використання/логіну в систему?
14. Все інше, що забули явно вказати, але про що повинні знати...

Після того, як ми створимо інвентаризацію, нам знадобляться процеси, щоб підтримувати її в актуальному стані, періодично переглядати її і переконатися, що люди не змінюють інфраструктуру і виробництво, не пройшовши відповідний процес (change management).  Наприклад, ми не повинні запускати незаплановані, незатверджені, необліковані системи, програмне забезпечення та послуги.

Нам потрібно задокументувати геть усі наші продукти, системи, все, що маємо і почати виправляти ті місця, де управління не є повністю зрілим, відповідно до найкращих інженерних практик. Чому? Будь-яка система є потенційним вектором атаки. Будь-яка ненадійна система - це потенційний незадоволений клієнт.  Будь-який інцидент безпеки або збій системи шкодить нашій репутації.  Будь-яке розслідування, проведене зовнішньою організацією, повинно виявити, що ми належним чином управляємо своїми системами та послугами, використовуючи найкращі інженерні практики та операції відповідно до існуючих стандартів.  Щоб досягти цього, ми повинні постійно бути в курсі того, що саме ми маємо.
--