Поділитися через

Рекомендації щодо забезпечення життєвого циклу розробки

Стосується цієї Power Platform рекомендації щодо контрольного списку Well-Architected Security:

СЕ:02 Підтримуйте безпечний життєвий цикл розробки, використовуючи посилений, переважно автоматизований і контрольований ланцюжок поставок програмного забезпечення. Включіть безпечний дизайн, використовуючи моделювання загроз, щоб захиститися від впроваджень, що порушують безпеку.

У цьому посібнику описано рекомендації щодо захисту вашого коду та середовища розробки шляхом застосування найкращих практик безпеки протягом усього циклу розробки.

В основі робочого навантаження лежать компоненти, які реалізують бізнес-логіку. Ці компоненти можуть бути поєднанням low-code елементів, таких як полотна додатків і потоків, і елементів, орієнтованих на код, таких як плагіни. Усі компоненти, з яких складається ваше робоче навантаження, не повинні мати дефектів безпеки, щоб забезпечити конфіденційність, цілісність і доступність.

Захист інфраструктурної площини за допомогою ідентифікації та мережевого контролю є важливим, але цього недостатньо. Запобігайте поганому виконанню Power Platform робочих навантажень і скомпрометованій діяльності в цих робочих навантаженнях, щоб зміцнити свою загальну безпеку. Процес інтеграції безпеки у ваш життєвий цикл розробки – це, по суті, процес посилення. Подібно до зміцнення ресурсів, посилення розробки коду також не залежить від контексту. Основна увага приділяється підвищенню безпеки, а не функціональним вимогам програми.

Визначення

Термін Визначення
Життєвий цикл розробки безпеки (SDL) Набір методів, наданих корпорацією Майкрософт, які підтримують вимоги щодо забезпечення безпеки та відповідності.
Життєвий цикл розробки програмного забезпечення (SDLC) Багатоступінчастий, системний процес розробки програмних систем.

Ключові стратегії дизайну

Заходи безпеки мають бути інтегровані на кількох етапах у ваш існуючий життєвий цикл розробки програмного забезпечення (SDLC), щоб забезпечити:

  • Вибір дизайну не призводить до прогалин у безпеці.
  • Low-code та code-first компоненти, а також конфігурація не створюють вразливостей через реалізацію, яку можна експлуатувати, та неправильну практику кодування.
  • Компоненти з низьким кодом і кодом, а також процеси розгортання не підробляються.
  • Вразливості, виявлені в результаті інцидентів, пом’якшуються.
  • Вимоги до відповідності не порушуються та не зменшуються.
  • Ведення журналу аудиту реалізовано у всіх середовищах.

У наступних розділах представлені стратегії безпеки для широко використовуваних фаз SDLC.

Етап вимог

Метою етапу вимог є збір та аналіз функціональних та нефункціональних вимог до робочого навантаження або нової ознаки робочого навантаження. Цей етап важливий, оскільки він сприяє створенню огорож, адаптованих до цілей робочого навантаження. Захист даних і цілісності вашого робочого навантаження має бути основною вимогою на кожному етапі життєвого циклу розробки.

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

Всі ці рішення повинні привести до хорошого визначення стану безпеки робочого навантаження. Задокументуйте вимоги безпеки в узгодженій специфікації та відобразіть їх у беклозі. У документі мають бути чітко визначені інвестиції в безпеку, а також компроміси та ризики, на які бізнес готовий піти, якщо інвестиції не будуть схвалені зацікавленими сторонами бізнесу. Наприклад, ви можете задокументувати необхідність використання IP-брандмауера в Power Platform середовищах для захисту даних вашої організації, обмежуючи Dataverse доступ лише до дозволених IP-адрес. Якщо зацікавлені сторони бізнесу не готові нести додаткові витрати на використання такого рішення, як керовані середовища, вони повинні бути готові прийняти ризик доступу до організаційних ресурсів із загальнодоступних місць, таких як кав’ярня. Як ще один приклад, уявіть, що ваша програма має підключатися до стороннього джерела даних. Power Platform Можливо, у вас є готовий конектор для цього, але він може не підтримувати вимоги до автентифікації, затверджені вашими командами безпеки. У цьому випадку зацікавлені сторони безпеки можуть бути готові прийняти ризик використання несхваленого методу автентифікації. Крім того, ви можете розглянути можливість використання спеціального з’єднувача, зважуючи переваги збільшення часу розробки та потенційної затримки проекту.

Збір вимог безпеки є важливою частиною цього етапу. Без цих зусиль етапи проектування та впровадження будуть засновані на незаявлених варіантах, що може призвести до прогалин у безпеці або зміни вимог, що збільшить час розробки. Можливо, вам доведеться змінити реалізацію пізніше, щоб забезпечити безпеку, яка може бути дорогою.

Етап проектування

На цьому етапі вимоги до безпеки перетворюються на технічні вимоги. У своєму технічному завданні зафіксуйте всі проектні рішення, щоб не допустити двозначності під час впровадження. Ось кілька типових завдань:

  • Визначте вимір безпеки архітектури. Накладіть на архітектуру елементи керування безпекою. Наприклад, практичні елементи керування межами ізоляції мережі, типи ідентичностей і методи автентифікації, необхідні для компонентів робочого навантаження, а також тип методів шифрування, які слід використовувати.

  • Оцініть можливості, надані платформою. важливо розуміти розподіл відповідальності між вами та Power Platform. Уникайте дублювання або дублювання за допомогою Power Platform вбудованих елементів керування безпекою. Ви отримаєте краще покриття безпеки та зможете перерозподілити ресурси розробки на потреби програми.

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

    Вибирайте лише надійні еталонні реалізації, шаблони, компоненти коду, сценарії та бібліотеки. У вашому дизайні також має бути визначено безпечне керування версіями. Залежності додатків повинні бути отримані від довірених сторін. Сторонні постачальники повинні відповідати вашим вимогам безпеки та ділитися своїм планом відповідального розкриття інформації. Про будь-який інцидент безпеки слід негайно повідомляти, щоб ви могли вжити необхідних заходів. Крім того, ваша організація може заборонити певні бібліотеки або впровадження посилань. Наприклад, навіть якщо він безпечний і не містить вразливостей, його все одно може бути відхилено, оскільки він використовує функції, які ще не схвалені вашою організацією, ліцензійні обмеження або модель підтримки еталонного впровадження.

    Щоб переконатися, що ці вказівки дотримуються, ведіть список затверджених та/або несхвалених фреймворків, бібліотек і постачальників, а також переконайтеся, що ваші виробники ознайомлені з цим списком. Коли це можливо, розмістіть огорожі в трубопроводах розробки, щоб підтримати список. Максимально автоматизуйте використання інструментів для сканування залежностей на наявність вразливостей.

  • Надійно зберігайте секрети застосування. Безпечно реалізуйте використання секретних секретів програм і попередньо спільних ключів, які використовує ваша програма. Облікові дані та секрети додатків ніколи не повинні зберігатися у вихідному коді робочого навантаження (app або flow). Використовуйте зовнішні ресурси, як-от Azure Key Vault, щоб гарантувати, що якщо ваш вихідний код стане доступним потенційному зловмиснику, ви не зможете отримати додатковий доступ.

  • Безпечне підключення до ваших даних. Скористайтеся надійними функціями безпеки для Microsoft Dataverse захисту ваших даних, такими як безпека на основі ролей і стовпців. Для інших джерел даних використовуйте конектори, які мають безпечні методи автентифікації. Уникайте запитів, які зберігають ім’я користувача та пароль у вигляді простого тексту. Уникайте HTTP для створення користувальницьких з’єднувачів.

  • Визначте, як кінцеві користувачі будуть взаємодіяти з робочим навантаженням і даними. Подумайте, чи матимуть користувачі прямий доступ до даних, який рівень доступу їм потрібен і звідки вони матимуть доступ до даних. Подумайте про те, як додатки будуть ділитися з кінцевими користувачами. Переконайтеся, що доступ до програми та даних матимуть лише ті, кому потрібен доступ до програми та даних. Уникайте складних моделей безпеки, які заохочують обхідні шляхи, щоб уникнути блокувальників безпеки.

  • Уникайте жорсткого кодування. Уникайте жорсткого кодування URL-адрес і ключів. Наприклад, уникайте жорсткого кодування в Power Automate дії HTTP URL-адреси або ключа до серверної служби. Замість цього використовуйте спеціальний з’єднувач або змінну середовища для URL-адреси та Azure Key Vault для ключа API.

  • Визначте плани тестування. Визначте чіткі тест-кейси для вимог безпеки. Оцініть, чи можете ви автоматизувати ці тести у своїх воронках продажів. Якщо у вашій команді є процеси ручного тестування, включіть вимоги безпеки для цих тестів.

Нотатка

На цьому етапі виконайте моделювання загроз. Моделювання загроз може підтвердити, що вибір дизайну відповідає вимогам безпеки, і виявити прогалини, які вам слід пом’якшити. Якщо ваше робоче навантаження обробляє дуже конфіденційні дані, інвестуйте в експертів з безпеки, які можуть допомогти вам провести моделювання загроз.

Початкове моделювання загроз має відбуватися на етапі проектування, коли визначається архітектура програмного забезпечення та високорівневий дизайн. Роблячи це на цьому етапі, ви зможете виявити потенційні проблеми з безпекою, перш ніж вони будуть включені в структуру системи. Однак ця вправа не є одноразовою. Це безперервний процес, який повинен тривати протягом усієї еволюції програмного забезпечення.

Докладнішу інформацію можна знайти в статті Рекомендації щодо аналізу загроз.

Етап розробки та тестування

На цьому етапі мета полягає в тому, щоб запобігти дефектам безпеки та фальсифікації коду, збірки та конвеєрів розгортання.

Бути добре навченим практикам безпечного коду

Команда розробників повинна мати підготовку з безпечних практик кодування. Наприклад, розробники повинні бути знайомі з концепціями безпеки для Microsoft Dataverse впровадження моделі безпеки з найменшими привілеями, політиками безпеки контенту для програм, керованих моделлю, щоб обмежити вбудовування в довірені домени, а також методами автентифікації з’єднувача/локального шлюзу.

Розробники повинні пройти це навчання, перш ніж вони почнуть працювати над Power Platform робочими навантаженнями.

Виконуйте внутрішнє рев’ю коду, щоб сприяти безперервному навчанню.

Використовуйте інструменти для аналізу коду

Solution Checker слід використовувати для Power Platform ресурсів, а вихідний код будь-якого традиційного коду може бути перевірений на наявність потенційних недоліків безпеки, включаючи наявність облікових даних у коді. Визначте можливі випадки розкриття облікових даних і секретних даних у вихідному коді та файлах конфігурації. Це гарний час, щоб проаналізувати, як облікові дані з’єднання оброблятимуться у продакшн.

Виконайте нечітке тестування

Використовуйте неправильно сформовані та неочікувані дані для перевірки вразливостей та перевірки обробки помилок, що особливо важливо з рішеннями, які включають Power Pages.

Напишіть достатню кількість коду

Коли ви зменшуєте обсяг коду, ви також зменшуєте ймовірність дефектів безпеки. Повторно використовуйте код і бібліотеки, які вже використовуються та пройшли перевірку безпеки, замість дублювання коду. Виявлення та перевірка версії програмного забезпечення з відкритим вихідним кодом, вразливостей та юридичних зобов’язань. Кількість ресурсів з відкритим вихідним кодом Power Platform зростає, тому цим не слід нехтувати. Коли це можливо, це слід обговорити на етапі проектування, щоб уникнути проблем в останню хвилину.

Захист середовищ розробників

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

Репозиторій вихідного коду також повинен бути захищений . Надавайте доступ до репозиторіїв коду за принципом «потреба знати» та зменшуйте розкриття вразливостей, наскільки це можливо, щоб уникнути атак. Проведіть ретельний процес перевірки коду на наявність вразливостей безпеки. Використовуйте для цього групи безпеки та застосовуйте процес затвердження, який ґрунтується на обґрунтуваннях бізнесу.

Безпечне розгортання коду

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

Підтримуйте актуальну інвентаризацію кожного компонента, інтегрованого у вашу програму

Кожен новий компонент, інтегрований у програму, збільшує поверхню атаки. Щоб забезпечити належну підзвітність і сповіщення про додавання або оновлення нових компонентів, вам слід провести інвентаризацію цих компонентів. Регулярно перевіряйте, чи ваш маніфест збігається з тим, що відбувається у вашому процесі складання. Це допомагає гарантувати, що жодні нові компоненти, які містять бекдори або інше шкідливе програмне забезпечення, не будуть додані несподівано.

Ми рекомендуємо використовувати Pipelines для Power Platform ваших розгортань. Розширюйте пайплайни за допомогою GitHub Actions. Якщо ви використовуєте робочі процеси GitHub, віддавайте перевагу завданням, автором яких є Microsoft. Крім того, перевіряйте завдання, оскільки вони виконуються в контексті безпеки вашої воронки продажів.

Дізнайтеся більше про використання принципів служб для розгортання.

Етап виробництва

Етап виробництва дає останню відповідальну можливість виправити прогалини в безпеці. Ведіть облік золотого зображення, яке випущено у виробництво.

Зберігайте артефакти у версіях

Ведіть каталог усіх розгорнутих активів та їх версій. Ця інформація корисна під час сортування інцидентів, коли ви усуваєте проблеми та коли повертаєте систему до робочого стану. Крім того, об’єкти версій можна порівнювати з опублікованими повідомленнями про поширені вразливості та вразливості (CVE). Для виконання цих порівнянь слід використовувати автоматизацію.

Екстрені виправлення

Ваша автоматизована воронка продажів повинна мати гнучкість для підтримки як регулярного, так і аварійного розгортання. Ця гнучкість важлива для підтримки швидких і відповідальних виправлень безпеки.

Випуск зазвичай пов’язаний із кількома каналами затвердження. Розгляньте можливість створення екстреного процесу, щоб прискорити виправлення безпеки. Процес може включати комунікацію між командами. Конвеєр повинен забезпечувати швидке розгортання вперед і відкочування, яке вирішує виправлення безпеки, критичні помилки та оновлення коду, які відбуваються поза звичайним життєвим циклом розгортання.

Нотатка

Завжди віддавайте перевагу виправленням безпеки, а не зручності. Виправлення системи безпеки не повинно призводити до регресії або помилки. Якщо ви хочете прискорити виправлення через аварійний конвеєр, уважно подумайте, які автоматизовані тести можна обійти. Оцінюйте цінність кожного тесту в порівнянні з часом виконання. Наприклад, модульні тести зазвичай завершуються швидко. Інтеграція або наскрізні тести можуть працювати тривалий час.

Тримайте різні середовища окремо

Виробничі дані не слід використовувати в нижчих** середовищах, оскільки ці середовища можуть не мати суворих засобів контролю безпеки, які має продакшн. Уникайте підключення з невиробничої програми до виробничої бази даних, а також підключення невиробничих компонентів до виробничих мереж.

Використовуйте прогресивну експозицію

Використовуйте поступове охоплення, щоб випускати функції для підмножини користувачів на основі обраних критеріїв. Якщо виникають проблеми, вплив на цих користувачів мінімізується. Цей підхід є поширеною стратегією зменшення ризиків, оскільки він зменшує площу поверхні. У міру того, як функція розвиватиметься, а ви впевненішими в гарантіях безпеки, ви зможете поступово випускати її для ширшого кола користувачів.

Фаза обслуговування

Мета цього етапу — переконатися, що рівень безпеки не погіршується з часом . SDLC – це безперервний гнучкий процес. Концепції, розглянуті на попередніх етапах, застосовуються до цього етапу, оскільки вимоги змінюються з часом.

Постійне вдосконалення. Постійно оцінювати та покращувати безпеку процесу розробки програмного забезпечення, враховуючи огляди коду, відгуки, отримані уроки та загрози, що розвиваються, а також нові функції, що з’являються Power Platform.

Виведення з експлуатації застарілих або невикористовуваних активів . Це зменшує площу поверхні застосування.

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

Постійно вдосконалюйте свої методи безпечного кодування, щоб бути в курсі ситуації з загрозами.

SDL в Microsoft Power Platform

Power Platform створено на основі культури й методології безпечного дизайну. Культура й методологія постійно зміцнюються за допомогою провідних галузевих принципів розробки безпечного ПЗ (Security Development Lifecycle, SDL) і практик моделювання загроз.

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

Моделювання загроз також передбачає всі зміни в послугах, які вже пройшли регулярні перевірки. Використання моделі STRIDE допомагає вирішити найпоширеніші проблеми з ненадійною конструкцією.

Принципи SDL Microsoft еквівалентні моделі зрілості підтримки програмного забезпечення (Software Assurance Maturity Model, SAMM). Обидві моделі створено з огляду на те, що захищений дизайн є частиною безпеки вебпрограми. Для отримання додаткової інформації див. 10 головних ризиків OWASP: заходи щодо їх пом’якшення у Power Platform.

Power Platform сприяння

Життєвий цикл розробки безпеки Microsoft (SDL) рекомендує безпечні методи, які можна застосовувати до життєвого циклу розробки. Щоб отримати додаткові відомості, див. Життєвий цикл розробки засобів безпеки Microsoft.

Defender для DevOps та інструменти SAST (Static Application Security Testing – тестування безпеки статей) включені до складу GitHub Advanced Security та Azure DevOps. Ці інструменти можуть допомогти вам відстежувати показник безпеки вашої організації.

Завдяки функції перевірки рішення можна виконувати широкий спектр перевірки статичного аналізу на ваших рішеннях проти набору найкращих практичних правил, та швидко визначати ці проблемні схеми. Див. розділ Використання засобу перевірки рішень для перевірки ваших рішень.

Контрольний список безпеки

Зверніться до повного зведення рекомендацій.

Контрольний список безпеки