Operational Support Systems for software development?
Доброго дня, колеги. Керівництво доросло до розуміння потреб чогось на зразок "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). Наприклад, ми не повинні запускати незаплановані, незатверджені, необліковані системи, програмне забезпечення та послуги. Нам потрібно задокументувати геть усі наші продукти, системи, все, що маємо і почати виправляти ті місця, де управління не є повністю зрілим, відповідно до найкращих інженерних практик. Чому? Будь-яка система є потенційним вектором атаки. Будь-яка ненадійна система - це потенційний незадоволений клієнт. Будь-який інцидент безпеки або збій системи шкодить нашій репутації. Будь-яке розслідування, проведене зовнішньою організацією, повинно виявити, що ми належним чином управляємо своїми системами та послугами, використовуючи найкращі інженерні практики та операції відповідно до існуючих стандартів. Щоб досягти цього, ми повинні постійно бути в курсі того, що саме ми маємо. ----------------------- Дякую. -- Regards, /oleh hrynchuk
Привет ! даже не знаю что тебе сказать :)... ...а табличка в Экселе чем тебе не подходит ? :) Просто если речь идет о "текстах программ и Проектов" то есть куча типа того же GitHub, или всякие "контроль версий". Ну а то что ты описал это из области когда Начальник говорит: "напишите мне Базу Данных" :-) в которой будет все-все что у меня есть упомянуто и описано"... Я спрошу у своих знакомых, кто разработкой "за бугром" занимается, может что то подскажут... Wednesday, January 25, 2023, 12:01:48 PM, Oleh Hrynchuk oleh.hrynchuk@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@euro.net.ua -- Это сообщение было проверено антивирусным ПО AVG на наличие вирусов. www.avg.com
привіт!
ні, Саша, там не так.
там складніше все набагато.
Ну, ніби з допомогою тутешніх колег розібрався, всім дякую...
далі вже спілкуємось з конкретною людиною глибше і по темі.
ср, 25 січ. 2023, 18:14 користувач Alexander V Soroka
Привет !
даже не знаю что тебе сказать :)... ...а табличка в Экселе чем тебе не подходит ? :)
Просто если речь идет о "текстах программ и Проектов" то есть куча типа того же GitHub, или всякие "контроль версий".
Ну а то что ты описал это из области когда Начальник говорит: "напишите мне Базу Данных" :-) в которой будет все-все что у меня есть упомянуто и описано"...
Я спрошу у своих знакомых, кто разработкой "за бугром" занимается, может что то подскажут...
Wednesday, January 25, 2023, 12:01:48 PM, Oleh Hrynchuk oleh.hrynchuk@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@euro.net.ua
-- Это сообщение было проверено антивирусным ПО AVG на наличие вирусов. www.avg.com _______________________________________________ uanog mailing list uanog@uanog.kiev.ua https://mailman.uanog.kiev.ua/mailman/listinfo/uanog
participants (2)
-
Alexander V Soroka -
Oleh Hrynchuk