Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Cклад інформаційних ресурсів

  2. Організація інформаційного забезпечення

  3. Структура і класифікація даних

  4. Безпека і захист інформації

ТИПОВА СТРУКТУРА робочого проекту

Заходи з підготовки засобу інформатизації до вводу в експлуатацію

  1. заходи щодо підготовки інформаційних баз та інтеграція даних

  2. опис методики приймальних випробувань тощо

  3. заходи щодо підготовки до навчання персоналу

Робоча документація

  1. програма Програма і методика приймальних випробувань

  2. план План розробки засобів інформатизації

    1. Перелік етапів розробки: Детальний розбиття процесу розробки на конкретні етапи (аналіз вимог, проектування, кодування, тестування, інтеграція тощо).

    2. Опис робіт для кожного етапу: Конкретні завдання та дії, які необхідно виконати на кожному етапі.

    3. Терміни виконання етапів: Календарний план з зазначенням тривалості кожного етапу та дат початку/завершення.

    4. Розподіл ресурсів: Інформація про необхідні ресурси (людські, технічні, фінансові) для кожного етапу.

    5. Методологія розробки: Опис підходів та методів, які будуть використовуватись в процесі розробки (наприклад, Agile, Waterfall).

    6. Критерії завершення етапів: Чіткі визначення того, що має бути досягнуто на кожному етапі, щоб вважати його завершеним.

    7. Управління змінами: Процедури обробки змін до вимог або плану в процесі розробки.

  3. план впровадження засобів інформатизації

    1. Встановлення та/або впровадження засобу інформатизації або його компонентів у сформованому випробувальному або промисловому середовищі.

    2. Проведення навчання фахівців замовника та/або технічного адміністратора засобу інформатизації, які забезпечують працездатність засобу інформатизації (за необхідності).   

    3. Залучення технічних ресурсів (у разі проведення в інфраструктурі технічного адміністратора та/або надавача хмарних послуг чи центру обробки даних).

  4. план міграції даних (інформації) (за необхідності)

...

    1. План складається для кожної окремої розробки 
  1. План міграції даних
    1. Якщо розробка передбачає міграцію даних, це описується безпосередньо в ТЗ до такої трозробки

Додатки



В требования по тестированию безопасности, вдруг надо


Забезпечити тестування безпеки згідно з концепцією OWASP (Open Web Application Security Project) TOP 10:

  • Порушення контролю доступу (A01:2021-Broken Access Control): Недостатня або некоректна реалізація механізмів контролю доступу, що дозволяє зловмисникам отримувати несанкціонований доступ до функцій або ресурсів Платформи.
  • Криптографічні помилки (A02:2021-Cryptographic Failures): Помилки, повʼязані з криптографією (або її відсутністю), що можуть призвести до витоку чутливих даних.
  • Інʼєкція (A03:2021-Injection): Вразливості, повʼязані з некоректною обробкою вхідних даних, що дозволяють зловмисникам впроваджувати та виконувати небезпечні команди на сервері бази даних або виконувати віддалений код.
  • Незахищений дизайн (A04:2021-Insecure Design): Вразливості, які виникають через недостатню увагу до безпеки під час проєктування Підсистеми або програмного забезпечення. Це означає, що проєктування Підсистеми не враховує потенційні загрози безпеці і не виконує необхідні заходи для захисту від таких загроз.
  • Помилкова конфігурація безпеки (A05:2021-Security Misconfiguration): Неправильна або необережна конфігурація Підсистеми, серверів, фреймворків або додатків, яка може призвести до вразливостей та спрощеного атакування.
  • Вразливі та застарілі компоненти (A06:2021-Vulnerable and Outdated Components): Використання сторонніх компонентів, бібліотек або фреймворків з відомими вразливостями, які можуть бути використані для атак на Платформу.
  • Помилки ідентифікації та автентифікації (A07:2021-Identification and Authentication Failures): Вразливості, повʼязані з недостатньою або некоректною реалізацією механізмів ідентифікації, аутентифікації та сесійного керування, які можуть дозволити зловмисникам отримати несанкціонований доступ до облікових записів користувачів.
  • Порушення цілісності програмного забезпечення та даних (A08:2021-Software and Data Integrity Failures): Збої програмного забезпечення та цілісності даних. Використання плагінів, бібліотек або модулів з ненадійних джерел, сховищ і мереж доставки вмісту (CDN). Незахищені конвеєри CI/CD, які можуть призвести до несанкціонованого доступу, зловмисного коду або компрометації Підсистеми.
  • Помилки ведення журналів та моніторингу безпеки (A09:2021-Security Logging and Monitoring Failures): Недостатній контроль, логування та моніторинг подій, що призводить до втрати можливості виявлення атак або відновлення після вторгнення.
  • Підробка запитів на стороні сервера (A10:2021-Server-Side Request Forgery): Вразливість, яка дозволяє зловмиснику маніпулювати сервером, щоб виконати несанкціоновані запити до внутрішніх ресурсів або зовнішніх систем.



ISO/IEC 27017 и ISO/IEC 27018 вам автоматом закроет Kubernetes в инфраструктуре прозоро
https://d1.awsstatic.com/certifications/iso_27017_certification.pdf
https://d1.awsstatic.com/certifications/iso_27018_certification.pdf (edited)современные международные стандарты (конкретика для юристов на основе которой можно запросить аудит на соответствие):

  • ISO/IEC 27001 – для построения системы управления информационной безопасностью
  • ISO/IEC 27017 – для обеспечения информационной безопасности в облачных средах
  • ISO/IEC 27018 – для защиты персональных данных в облачных сервисах
  • ISO/IEC 15408 (Common Criteria) – для оценки безопасности программного обеспечения
  • NIST SP 800-53 – для реализации требований к контролю безопасности (на это тестировали прозоро в 24 году)
  • GDPR - вот честно не скажу, есть ли он в законе украины об информации и защите информации но движения были в эту сторону


https://mof.gov.ua/storage/files/National%20Revenue%20Strategy_2030_.pdf (edited)