Споделяне чрез

Препоръки за осигуряване на жизнения цикъл на разработката

Отнася се за тази Power Platform препоръка за контролен списък за добре архитектурирана сигурност:

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

Това ръководство описва препоръките за защита на вашия код и среда за разработка чрез прилагане на най-добрите практики за защита през целия цикъл на разработка.

В основата на работното натоварване са компонентите, които прилагат бизнес логиката. Тези компоненти могат да бъдат комбинация от елементи с нисък код като приложения и потоци за платно и елементи на първо място като плъгини. Всички компоненти, които съставляват вашето работно натоварване, не трябва да имат дефекти в защитата, за да се гарантира поверителност, цялост и наличност.

Защитата на инфраструктурната равнина с контроли за самоличност и работа в мрежа е важна, но не е достатъчна. Предотвратете лошо изпълнение на Power Platform работни натоварвания и компрометирани дейности в тези натоварвания, за да укрепите цялостното си състояние на защитата. Процесът на интегриране на сигурността във вашия жизнен цикъл на разработка е по същество процес на втвърдяване. Точно като втвърдяването на ресурсите, затягането на разработката на код също е контекстно-зависимо. Фокусът е върху повишаването на сигурността, а не върху функционалните изисквания на приложението.

Дефиниции

Термин Дефиниция
Жизнен цикъл на разработката на сигурността (SDL) Набор от практики, предоставени от Microsoft, които поддържат изисквания за осигуряване на защитата и съответствието.
Жизнен цикъл на разработката на софтуер (SDLC) Многоетапен, систематичен процес за разработване на софтуерни системи.

Ключови стратегии за проектиране

Мерките за сигурност трябва да бъдат интегрирани в множество точки във вашия съществуващ жизнен цикъл на разработката на софтуер (SDLC), за да се гарантира:

  • Изборът на дизайн не води до пропуски в сигурността.
  • Компонентите с нисък код и код, както и конфигурацията, не създават уязвимости поради експлоатируема реализация и неправилни практики за кодиране.
  • Компонентите и процесите на внедряване с нисък код и код на първо място не са подправени.
  • Уязвимостите, разкрити чрез инциденти, се смекчават.
  • Изискванията за съответствие не са компрометирани или намалени.
  • Регистрирането на одита е внедрено във всички среди.

Следващите раздели предоставят стратегии за сигурност за често практикуваните фази на SDLC.

Фаза на изискванията

Целта на фазата на изискванията е да се съберат и анализират функционалните и нефункционалните изисквания за работно натоварване или нова характеристика на работното натоварване. Тази фаза е важна, защото улеснява създаването на парапети, които са съобразени с целите на работното натоварване. Защитата на данните и целостта на вашето работно натоварване трябва да бъде основно изискване през всяка фаза от жизнения цикъл на разработката.

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

Всички тези решения трябва да доведат до добро определяне на състоянието на сигурността на работното натоварване. Документирайте изискванията за сигурност в договорена спецификация и ги отразете в изоставането. Документът трябва изрично да посочва инвестициите в сигурност и компромисите и рисковете, които бизнесът е готов да поеме, ако инвестициите не бъдат одобрени от заинтересованите страни на бизнеса. Например можете да документирате необходимостта от използване на IP защитна стена в Power Platform среди, за да защитите данните на вашата организация, като ограничите Dataverse достъпа само до разрешени IP местоположения. Ако бизнес заинтересованите страни не желаят да поемат допълнителните разходи за използване на решение като Управлявани среди, те трябва да са готови да приемат риска от достъп до организационни ресурси от обществени места, като кафене. Като друг пример, представете си, че вашето приложение трябва да се свърже с източник на данни на трета страна. Power Platform Може да има готов конектор за това, но може да не поддържа изискванията за удостоверяване, одобрени от вашите екипи по сигурността. В този случай заинтересованите страни по сигурността може да са готови да приемат риска от използването на неодобрен метод за удостоверяване. Като алтернатива можете да проучите използването на персонализиран конектор, като същевременно претеглите ползите от увеличеното време за разработка и потенциалното забавяне на проекта.

Събирането на изискванията за сигурност е критична част от тази фаза. Без тези усилия фазите на проектиране и изпълнение ще се основават на неизказани избори, което може да доведе до пропуски в сигурността или променящи се изисквания, които ще увеличат времето за разработка. Може да се наложи да промените внедряването по-късно, за да осигурите сигурността, което може да бъде скъпо.

Фаза на проектиране

По време на тази фаза изискванията за сигурност се преобразуват в технически изисквания. Във вашата техническа спецификация документирайте всички дизайнерски решения, за да предотвратите неяснота по време на изпълнението. Ето някои типични задачи:

  • Определете измерението на защитата на архитектурата. Наслагване на архитектурата с контроли за сигурност. Например контроли, които са практични за границите на изолацията на мрежата, типовете самоличности и методите за удостоверяване, необходими за компонентите на работното натоварване, и типа на методите за шифроване, които да се използват.

  • Оценете възможностите, предоставени от платформата. Важно е да разберете разделението на отговорността между вас и Power Platform. Избягвайте припокриване или дублиране с Power Platform вградените контроли за сигурност. Ще получите по-добро покритие на сигурността и ще можете да преразпределите ресурсите за разработка към нуждите на приложението.

    Например, вместо да създавате персонализирана логика, която реактивно идентифицира и предупреждава за неодобрени модели на използване в приложения и потоци, използвайте правила за данни, за да категоризирате как могат да се използват конектори.

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

    За да сте сигурни, че тези указания се спазват, поддържайте списък с одобрени и/или неодобрени рамки, библиотеки и доставчици и се уверете, че вашите производители са запознати с този списък. Когато е възможно, поставете парапети в тръбопроводите за разработка, за да поддържате списъка. Доколкото е възможно, автоматизирайте използването на инструменти за сканиране на зависимости за уязвимости.

  • Съхранявайте сигурно тайните на приложението. Внедрете сигурно използването на тайни на приложението и предварително споделени ключове, които вашето приложение използва. Идентификационните данни и тайните на приложението никога не трябва да се съхраняват в изходния код на работното натоварване (приложение или поток). Използвайте външни ресурси като Azure Key Vault, за да гарантирате, че ако вашият изходен код стане достъпен за потенциален нападател, не може да бъде получен допълнителен достъп.

  • Свържете се сигурно с данните си. Възползвайте се от силните функции за защита, които Microsoft Dataverse предлагат защита на вашите данни, като например защита на ниво роли и на ниво колона. За други източници на данни използвайте конектори, които имат защитени методи за удостоверяване. Избягвайте заявки, които съхраняват потребителско име и парола в обикновен текст. Избягвайте HTTP за създаване на персонализирани конектори.

  • Определете как крайните потребители ще взаимодействат с работното натоварване и данните. Помислете дали потребителите ще имат директен достъп до данните, от какво ниво на достъп се нуждаят и откъде ще имат достъп до данните. Помислете как приложенията ще бъдат споделяни с крайните потребители. Уверете се, че само тези, които се нуждаят от достъп до приложението и данните, ще имат достъп. Избягвайте сложни модели за защита, които насърчават заобиколни решения, за да избегнете блокиране на защитата.

  • Избягвайте твърдо кодиране. Избягвайте твърдо кодиране на URL адреси и ключове. Например, избягвайте твърдо кодиране в Power Automate HTTP действие на URL адреса или ключа към бекенд услугата. Вместо това използвайте персонализиран конектор или използвайте променлива на средата за URL адреса и Azure Key Vault за ключа на API.

  • Определете тестови планове. Определете ясни тестови случаи за изискванията за сигурност. Преценете дали можете да автоматизирате тези тестове във вашите тръбопроводи. Ако вашият екип има процеси за ръчно тестване, включете изисквания за защита за тези тестове.

Бележка

Извършете моделиране на заплахите по време на тази фаза. Моделирането на заплахи може да потвърди, че изборът на дизайн е в съответствие с изискванията за сигурност и да разкрие пропуски, които трябва да смекчите. Ако вашето работно натоварване обработва силно чувствителни данни, инвестирайте в експерти по сигурността, които могат да ви помогнат да извършите моделиране на заплахите.

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

За повече информация вижте Препоръки за анализ на заплахите.

Фаза на разработка и тестване

По време на тази фаза целта е да се предотвратят дефекти в сигурността и подправяне на кода, изграждането и внедряването на тръбопроводи.

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

Екипът за разработка трябва да има обучение за сигурни практики за кодиране. Например разработчиците трябва да са запознати с концепциите за сигурност, за Microsoft Dataverse да внедрят модел за защита с най-малко привилегии, правила за защита на съдържанието за приложения, управлявани от модел, за да се ограничи вграждането до надеждни домейни, и методи за удостоверяване на конектор/локален шлюз.

От разработчиците трябва да се изисква да завършат това обучение, преди да започнат да работят по Power Platform работни натоварвания.

Извършвайте вътрешни проверки на партньорски кодове, за да насърчите непрекъснатото обучение.

Използване на инструменти за анализ на код

Solution Checker трябва да се използва за Power Platform ресурси, а изходният код на всеки традиционен код може да бъде проверен за потенциални пропуски в сигурността, включително наличието на идентификационни данни в кода. Идентифицирайте възможни случаи на идентификационни данни и разкриване на тайни данни в изходния код и конфигурационните файлове. Това е подходящ момент да прегледате как ще се обработват идентификационните данни за връзка в производството.

Извършете Fuzz тестване

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

Напишете достатъчно код

Когато намалите отпечатъка на кода си, намалявате и шансовете за дефекти в сигурността. Използвайте повторно код и библиотеки, които вече се използват и са преминали през проверка на сигурността, вместо да дублират код. Откриване на софтуер с отворен код и проверка на версията, уязвимостта и законовите задължения. Има нарастващо количество ресурси с отворен код Power Platform , така че това не бива да се пренебрегва. Когато е възможно, това трябва да се обсъди по време на фазата на проектиране, за да се избегнат проблеми в последния момент.

Защита на средите за разработчици

Работните станции за разработчици трябва да бъдат защитени със силен контрол на мрежата и самоличността, за да се предотврати излагането. Уверете се, че актуализациите на защитата се прилагат старателно.

Хранилището на изходния код също трябва да бъде защитено . Предоставяне на достъп до хранилища на код въз основа на принципа "необходимост да се знае" и намаляване на излагането на уязвимости, доколкото е възможно, за да се избегнат атаки. Имайте задълбочен процес за преглед на кода за уязвимости в сигурността. Използвайте групи за защита за тази цел и внедрете процес на одобрение, който се основава на бизнес обосновки.

Защитени внедрявания на код

Не е достатъчно само да защитите кода. Ако работи в експлоатируеми тръбопроводи, всички усилия за сигурност са напразни и непълни. Средите за изграждане и издаване също трябва да бъдат защитени , защото искате да предотвратите злонамерен код на лоши участници във вашия конвейер.

Поддържайте актуален опис на всеки компонент, който е интегриран във вашето приложение

Всеки нов компонент, който е интегриран в приложението, увеличава повърхността на атаката. За да осигурите правилна отчетност и предупреждение при добавяне или актуализиране на нови компоненти, трябва да имате опис на тези компоненти. Редовно проверявайте дали манифестът ви съвпада с това, което е в процеса на изграждане. Това помага да се гарантира, че няма да се добавят неочаквано нови компоненти, които съдържат задни вратички или друг зловреден софтуер.

Препоръчваме да използвате Pipelines за Power Platform вашите внедрявания. Разширете тръбопроводите с помощта на GitHub Actions. Ако използвате работни потоци на GitHub, предпочитайте задачи, създадени от Microsoft. Също така проверявайте задачите, защото те се изпълняват в контекста на защитата на вашия тръбопровод.

Разгледайте използването на принципали на услуги за внедряване.

Производствена фаза

Производствената фаза представлява последната отговорна възможност за отстраняване на пропуските в сигурността. Водете запис на златното изображение, което е пуснато в производството.

Запазване на версионни артефакти

Поддържайте каталог на всички внедрени активи и техните версии. Тази информация е полезна по време на триаж на инциденти, когато смекчавате проблеми и когато връщате системата в работно състояние. Версираните активи могат също да бъдат сравнени с публикуваните известия за често срещани уязвимости и експозиции (CVE). Трябва да използвате автоматизация, за да извършите тези сравнения.

Аварийни поправки

Вашият автоматизиран дизайн на тръбопровода трябва да има гъвкавостта да поддържа както редовни, така и аварийни внедрявания. Тази гъвкавост е важна за поддържане на бързи и отговорни корекции на сигурността.

Освобождаването обикновено се свързва с множество портове за одобрение. Помислете за създаване на авариен процес за ускоряване на корекциите на защитата. Процесът може да включва комуникация между екипите. Конвейерът трябва да позволява бързо разгръщане и връщане назад, които се отнасят до корекции на защитата, критични грешки и актуализации на кода, които се случват извън редовния жизнен цикъл на внедряване.

Бележка

Винаги давайте приоритет на корекциите на сигурността пред удобството. Корекцията на сигурността не трябва да въвежда регресия или грешка. Ако искате да ускорите корекцията чрез авариен тръбопровод, внимателно обмислете кои автоматизирани тестове могат да бъдат заобиколени. Оценете стойността на всеки тест спрямо времето за изпълнение. Например, тестовете обикновено завършват бързо. Интеграционните или тестовете от край до край могат да работят дълго време.

Отделете различните среди

Производствените данни не трябва да се използват в по-ниски среди** , тъй като тези среди може да нямат строгите контроли за сигурност, които има производството. Избягвайте свързването от непроизводствено приложение към производствена база данни и избягвайте свързването на непроизводствени компоненти към производствени мрежи.

Използвайте прогресивна експозиция

Използвайте прогресивно излагане на функциите за освобождаване на подгрупа от потребители въз основа на избрани критерии. Ако има проблеми, въздействието е сведено до минимум за тези потребители. Този подход е често срещана стратегия за намаляване на риска, тъй като намалява повърхността. Тъй като функцията узрява и имате повече доверие в гаранциите за сигурност, можете постепенно да я пуснете за по-широк набор от потребители.

Фаза на поддръжка

Целта на тази фаза е да се гарантира, че позицията на сигурността няма да се разпадне с течение на времето. SDLC е непрекъснат гъвкав процес. Понятията, обхванати в предходните фази, се прилагат за тази фаза, тъй като изискванията се променят с течение на времето.

Непрекъснато усъвършенстване. Непрекъснато оценявайте и подобрявайте сигурността на процеса на разработка на софтуер, като вземате предвид прегледите на кода, обратната връзка, научените уроци и развиващите се заплахи, както и новите функции, предоставени от Power Platform.

Извеждане от експлоатация на наследени активи , които са остарели или вече не се използват. Това намалява повърхността на приложението.

Поддръжката включва и корекции на инциденти. Ако се открият проблеми в производството, те трябва незабавно да бъдат интегрирани обратно в процеса, така че да не се повтарят.

Непрекъснато подобрявайте практиките си за защитено кодиране, за да сте в крак с пейзажа на заплахите.

SDL в Microsoft Power Platform

Power Platform е изграден върху култура и методология на защитен дизайн. Както културата, така и методологията непрекъснато се подсилват чрез водещите в индустрията жизнен цикъл на развитие на сигурността (SDL) и моделиране на заплахи практики на Microsoft.

Процесът на преглед на моделирането на заплахи гарантира, че заплахите са идентифицирани по време на фазата на проектиране, смекчени и валидирани, за да се гарантира, че са смекчени.

Моделирането на заплахи също отчита всички промени в услугите, които вече са активни чрез непрекъснати редовни прегледи. Разчитането на модела STRIDE помага за справяне с най-често срещаните проблеми с несигурния дизайн.

SDL на Microsoft е еквивалентен на OWASP Software Assurance Maturity Model (SAMM). И двете са изградени на предпоставката, че защитеният дизайн е неразделна част от сигурността на уеб приложенията. За повече информация вижте OWASP Топ 10 риска: Смекчаване в Power Platform.

Power Platform улесняване

Жизненият цикъл на разработката на Microsoft Security (SDL) препоръчва защитени практики, които можете да приложите към жизнения цикъл на разработката. За повече информация вижте Жизнен цикъл на разработката на защитата на Microsoft.

Defender for DevOps и инструментите SAST (Static Application Security Testing) са включени като част от GitHub Advanced Security и Azure DevOps. Тези инструменти могат да ви помогнат да проследявате оценка на защитата за вашата организация.

С помощта на функцията за проверка на решение можете да изпълните проверка с богат статичен анализ на решенията си срещу набор от правила за най-добри практики и бързо да разпознаете тези проблематични модели. Вижте Използване на проверка на решения за проверка на вашите решения.

Контролен списък за сигурност

Вижте пълния набор от препоръки.

Контролен списък за сигурност

  • Last updated on