[uanog] Operational Support Systems for software development?

[Alexander V Soroka]

Привет !

даже не знаю что тебе сказать :)...
...а табличка в Экселе чем тебе не подходит ? :)

Просто если речь идет о "текстах программ и Проектов" то есть куча 
типа того же GitHub, или всякие "контроль версий".

Ну а то что ты описал это из области когда Начальник говорит: 
"напишите мне Базу Данных" :-)  в которой будет все-все что у меня есть упомянуто и описано"...

Я спрошу у своих знакомых, кто разработкой "за бугром" занимается, 
может что то подскажут...

Wednesday, January 25, 2023, 12:01:48 PM, Oleh Hrynchuk oleh.hrynchuk at gmail.com you wrote:
OH> Доброго дня, колеги.

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

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

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

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

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

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


OH> Дякую.



-- 
Best regards,
Alexander V Soroka       http://www.svr.ua/
AS106-RIPE
mailto:alex at euro.net.ua


-- 
Это сообщение было проверено антивирусным ПО AVG на наличие вирусов.
www.avg.com