Jaa

Kehityksen elinkaaren suojaussuosituksia

  • Artikkeli

Koskee tätä Power Platform hyvin suunniteltua tietoturvan tarkistuslistasuositusta:

SE:02 Suojatun kehittämisen elinkaaren ylläpitäminen käyttämällä karaistua, suurimmaksi osaksi automatisoitua ja seurattavaa ohjelmiston toimitusketjua. Ota suojattu rakenne käyttöön käyttämällä uhkien mallinnusta suojana suojauksen ohittavia toteutuksia vastaan.

Tässä oppaassa käsitellään suosituksia koodin ja kehitysympäristön suojaamiseen käyttämällä suojauksen parhaita käytäntöjä koko kehitysjakson ajan.

Työkuorman ytimenä ovat liiketoimintalogiikkaa toteuttavat komponentit. Nämä komponentit voivat olla yhdistelmä vähäkoodisia elementtejä, kuten pohjaan perustuvia sovelluksia ja työnkulkuja, sekä koodipohjaisia elementtejä, kuten laajennuksia. Missään työkuorman muodostavista komponenteista ei saa olla tietoturvavikoja, sillä näin voidaan varmistaa luottamuksellisuus, eheys ja käytettävyys.

Infrastruktuuritason suojaaminen käyttäjätietojen ja verkkopalvelujen hallinnalla on tärkeää muttei yksistään riittävää. Power Platform -työkuormien huonon toteuttamisen ja kyseisten työkuormien vaarantumisen estäminen vahvistaa suojauksen tilaa yleisesti. Suojauksen integrointi kehityksen elinkaareen on viime kädessä vahvistamisprosessi. Resurssien vahvistamisen tavoin myöskään koodikehityksen tiivistäminen ei kontekstisidonnaista. Tarkoitus on siis parantaa suojausta eikä sovelluksen toiminnallisia tarpeita.

Määritelmät

Termi Määritelmä
Turvallisuuskehityksen elinkaari (SDL) Joukko käytäntöjä Microsoft , jotka tukevat tietoturvan varmistusta ja vaatimustenmukaisuusvaatimuksia.
Ohjelmistokehityksen elinkaari (SDLC) Monivaiheinen ohjelmallinen ohjelmistojärjestelmien kehitysprosessi.

Tärkeimmät suunnittelustrategiat

Suojaustoimet on integroitava useissa kohdissa nykyiseen ohjelmistokehityksen elinkaareen (SDLC). Se mahdollistaa seuraavien varmistamisen:

  • Suunnittelussa tehdyt valinnat eivät jätä turvallisuusaukkoja.
  • Vähäkoodiset ja koodipohjaiset komponentit sekä määrityksestä eivät luo haavoittuvuuksia heikkouksille altistavan toteutuksen ja virheellisten koodauskäytäntöjen vuoksi.
  • Vähäkoodisia ja koodipohjaisia komponentteja ja käyttöönottoprosesseja ei ole peukaloitu.
  • Tapausten kautta paljastuneet haavoittuvuudet korjataan.
  • Vaatimustenmukaisuusvaatimukset eivät ole vaarantuneet tai heikentyneet.
  • Valvontalokien käyttö toteutetaan kaikissa ympäristöissä.

Seuraavissa osissa käsitellään ohjelmistokehityksen elinkaarissa yleisesti käytettyjen vaiheiden suojausstrategioita.

Vaatimusvaihe

Vaatimusvaiheen tavoite on kerätä ja analysoida työkuorman tai työkuorman uuden ominaisuuden toiminnalliset ja ei-toiminnalliset vaatimukset. Tämä vaihe on tärkeä, sillä se helpottaa työkuorman tavoitteiden mukaan räätälöityjen varmistusten luontia. Työkuorman tietojen ja eheyden turvaamisen on oltava ydinvaatimus kehityksen elinkaaren jokaisessa vaiheessa.

Jos kyse on esimerkiksi työkuormasta, jossa käyttäjät syöttävät ja muokkaavat tietoja sovelluksessa. Suojauksen suunnittelussa tehtävien valintojen on varmistettava käyttäjän tietojen käyttötilanne esimerkiksi todentamalla ja valtuuttamalla käyttäjätiedot sekä sallittava tiedoissa vain luvalliset toiminnot. Ei-toiminnalliset vaatimukset kattavat saatavuuden, käytettävyyden ja ylläpidettävyyden. Suojauksessa tehtävien valintojen on sisällettävä segmentointirajat, palomuurin saapuva ja lähtevä liikenne sekä muut yleiset suojauskysymykset.

Kaikkien näiden päätösten on johdettava työkuorman suojauksen tilanteen hyvään määritelmään. Suojaustarpeet dokumentoidaan sovitulla tavalla ja niitä käytetään myös keskeneräisissä töissä. Dokumentoinnin on ilmaista selkeästi suojaukseen tehtävät investoinnit sekä kompromissit ja riskit, joihin yritys on valmis, jos liiketoiminnan sidosryhmät eivät hyväksy investointeja. Dokumentaatio voi esimerkiksi sisältää tarpeen käyttää IP-palomuuria Power Platform -ympäristöissä, sillä sen avulla voidaan turvat organisaation tiedot rajoittamalla Dataversen käyttö vain sallituille IP-sijainneille. Jos liiketoiminnan sidosryhmät eivät ole valmiita hyväksymään hallittujen ympäristöjen kaltaisen ratkaisun aiheuttamia lisäkustannuksia, kyseisten sidosryhmien on oltava valmiita hyväksymään riski, että organisaation resursseja voidaan käyttää julkisista sijainneista, kuten kahviloista. Toinen esimerkki on tilanne, jossa sovellus on yhdistettävä kolmannen osapuolen tietolähteeseen. Power Platformissa voi olla tätä varten valmis yhdistin, joka ei kuitenkaan ehkä tue tietoturvatiimien hyväksymiä todennusmenetelmiä. Tässä tapauksessa tietoturvan sidosryhmät ovat ehkä valmiita hyväksymään riskin, joka liittyy hyväksymättömän todennusmenetelmän käyttämiseen. Vaihtoehtoisesti voidaan ehkä perehtyä mukautetun yhdistimen käyttämiseen samalla, kun pohditaan, onko se kannattavaa kehitykseen kuluvan lisäajan ja projektin mahdollisen viivästymisen vuoksi.

Suojausvaatimusten kerääminen on tämän vaiheen olennainen osa. Jos sitä ei tehdä, suunnittelu- ja toteutusvaiheet perustuvat ilmaisemattomiin valintoihin, mikä voi johtaa tietoturva-aukkoihin tai kehitysaikaa pidentäviin vaatimusten muuttumiseen. Suojauksen ottaminen huomioon voi ehkä edellyttää toteutuksen muuttamista myöhemmin, mikä voi olla kallista.

Suunnitteluvaihe

Tämän vaiheen aikana suojausvaatimukset muunnetaan teknisiksi vaatimuksiksi. Kaikkien suunnitteluun liittyvien päätösten dokumentointi teknisiin tietoihin estää epäselvyydet toteutuksen aikana. Tyypillisiä tehtäviä:

  • Arkkitehtuurin suojausdimension määrittäminen. Suojauksen hallinnan asettaminen arkkitehtuurin päälle. Kyse on esimerkiksi verkkopalvelujen eristysrajojen kannalta kätevästä hallinnasta, työkuorman komponenteissa tarvittavista käyttäjätiedoista ja todennusmenetelmistä sekä käytettävistä todennusmenetelmätyypeistä.

  • Ympäristöön sisältyvien etujen arviointi. On tärkeää ymmärtää, mikä on omalla vastuulla ja mikä Power Platformin. Power Platformin oman suojauksen hallinnan toistamista tai sen kanssa päällekkäistä hallintaa on syytä välttää. Tällä tavoin suojauksesta tulee kattavampi ja kehitysresursseja voidaan kohdistaa sovelluksen tarpeisiin.

    Sen sijaan että esimerkiksi käytettäisiin mukautettua logiikkaa, joka reagoivasti tunnistaa luvattomat sovellusten ja työnkulkujen käyttötavat sekä tekee niistä ilmoituksen, yhdistimien sallittu käyttö voidaan luokitella tietojen menetyksen estämiskäytäntöjen avulla.

    Valitse vain luotetut viitetoteutukset, mallit, koodikomponentit, komentosarjat ja kirjastot. Suunnitelmassa on määritettävä myös turvallinen versionhallinta. Sovellusten riippuvaisuuksien on oltava peräisin luotetuilta osapuolilta. Kolmannen osapuolen toimittajien pitäisi pystyä täyttämään turvallisuusvaatimuksesi ja jakamaan vastuullinen tiedonantosuunnitelmansa. Mahdolliset suojaustapaukset on ilmoitettava heti, jota tarvittavat toimet voidaan tehdä. On lisäksi mahdollista, että tietyt kirjastot tai viitetoteutukset on kielletty organisaatiossa. Kielto voi esimerkiksi koskea sellaista kohdetta, joka on turvallinen eikä sisällä haavoittuvuuksia mutta jossa käytetään ominaisuuksia, joita organisaatio ei ole vielä hyväksynyt. Kyse voi olla myös käyttöoikeuksien rajoituksista tai viitetoteutuksen tukimallista.

    Ohjeistuksen noudattaminen voidaan varmistaa ylläpitämällä luetteloa hyväksytyistä kehyksistä, kirjastoista ja toimittajista sekä/tai niistä, joita ei hyväksytä. Lisäksi on varmistettava, että tekijät tuntevat tämän luettelon. Luettelon tueksi kehitysputkiin kannattaa asettaa mahdollisuuksien mukaan varmistuksia luettelon tueksi. Haavoittuvuuksien etsimiseen riippuvaisuuksista käytettävien työkalujen käyttö kannattaa automatisoida mahdollisimman pitkälle.

  • Sovelluksen salaisuuksien turvallinen tallentaminen. Sovelluksen salaisuuksien ja sovelluksen käyttämien valmiiksi jaettujen avaimien käyttö on toteutettava turvallisesti. Tunnistetietoja ja sovelluksen salaisuuksia ei saa koskaan tallentaa työkuorman (sovelluksen tai työnkulun) lähdekoodiin. Käyttämällä ulkoisia resursseja, kuten Azure Key Vaultia, voidaan varmistaa, että jos mahdollinen hyökkääjä pääsee käsiksi lähdekoodiin, tämä ei saa muita käyttöoikeuksia.

  • Yhteyden muodostaminen turvallisesti tietoihin. Tietojen turvaamiseen kannattaa käyttää vahvoja Microsoft Dataversen ominaisuuksia, kuten roolipohjaista ja saraketason suojausta. Muissa tietolähteissä kannattaa käyttää yhdistimiä, joissa on turvalliset todennusmenetelmät. Käyttäjänimen ja salasanan tekstimuodossa tallentavia kyselyjä on syytä välttää. HTTP:n käyttöä mukautettujen yhdistimien luontiin on syytä välttää.

  • Tapa, jolla loppukäyttäjät käyttävät työkuorma ja tietoja, on määritettävä. Kannattaa harkita, tarvitsevatko käyttäjät tietojen suoran käyttöoikeuden, millä tasolla he tarvitsevat käyttöoikeuden ja mistä he käyttävät tietoja. Kannattaa pohtia, miten sovellukset jaetaan loppukäyttäjien kanssa. On varmistettava, että käyttöoikeudet ovat vain niillä, joiden on käytettävä sovellusta ja tietoja. Monimutkaisia suojausmalleja on syytä välttää, sillä estävät suojaustoimet kannustavat etsimään kiertoteitä.

  • Kiinteää koodausta ei kannata käyttää. URL-osoitteissa ja avaimissa ei kannatta käyttää kiinteää koodausta. Kiinteää koodausta kannattaa välttää esimerkiksi Power Automaten HTTP-toiminnon URL-osoitteessa tai taustapalvelun avaimessa. Sen sijaan kannattaa käyttää mukautettua yhdistintä ja ympäristömuuttujaa URL-osoitteessa ja Azure Key Vaultia ohjelmointirajapinnan avaimessa.

  • Testisuunnitelmien määrittäminen. Suojausvaatimuksia varten on määritettävä selkeät testitapaukset. On arvioitava, voidaanko kyseiset testit automatisoida putkissa. Jos tiimillä on manuaalisia testausprosesseja, suojausvaatimukset kannattaa sisällyttää näihin testeihin.

Muistiinpano

Uhkien mallinnus suoritetaan tässä vaiheessa. Uhkien mallinnus voi vahvistaa, että suunnitteluvalinnat vastaavat suojausvaatimuksia, sekä tuoda esiin korjattavat aukot. Jos työkuorma käsittelee erittäin arkaluonteisia tietoja, kannattaa panostaa tietoturva-asiantuntijoihin auttamaan uhkien mallinnuksessa.

Ensimmäinen uhkien mallinnusharjoitus on tehtävä suunnitteluvaiheessa, kun ohjelmiston arkkitehtuuria ja ylätason rakennetta määritetään. Mallinnuksen suorittaminen tässä vaiheessa auttaa tunnistamaan mahdollisuus tietoturvaongelmat, ennen kuin ne sisällytetään järjestelmän rakenteeseen. Tämä harjoitus ei kuitenkaan ole kertaluonteinen, vaan se on jatkuva prosessi, jonka on jatkuttava koko ohjelmiston kehittymisen ajan.

Lisätietoja on ohjeaiheessa Uhka-analyysejä koskevat suositukset.

Kehitys- ja testausvaihe

Tämän vaiheen aikana tavoitteena on estää tietoturvaviat koodissa, koontiversiossa ja käyttöönottoputkissa sekä niiden peukalointi.

Hyvä koulutus turvallisissa koodauskäytännöissä

Kehitystiimillä on oltava turvallisten koodauskäytäntöjen koulutusta. Kehittäjien on esimerkiksi tunnettava Microsoft Dataversen suojauskäsitteet, jotta he voivat toteuttaa vähäisimmän oikeuden suojausmallin, mallipohjaisten sovellusten sisällön upottamisen rajoittamista luotetuilla toimialueilla koskevat suojauskäytännöt sekä yhdistimen tai paikallisen yhdyskäytävän todennusmenetelmät.

Kehittäjiä on edellytettävä suorittamaan tämä koulutus ennen Power Platform -työkuormien käsittelyn aloittamista.

Jatkuvaan oppimiseen voidaan kannustaa suorittamalla sisäisiä koodauksen vertaisarviointia.

Koodin analyysityökalujen käyttäminen

Ratkaisun tarkistustoimintoa on käytettävä Power Platform -resursseissa. Perinteiden koodin lähdekoodista voidaan puolestaan tarkistaa mahdollisuus tietoturvaviat, mukaan lukien tunnistetietojen esiintyminen koodissa. Tunnistetietojen ja salaisuuksien mahdollisen esiintymisen tunnistaminen lähdekoodissa ja määritystiedostoissa. Tässä vaiheessa on hyvä arvioida, miten yhteyden tunnistetietoja käsitellään tuotannossa.

Sumeustestaus

Huonosti muotoiltujen tai odottamattomien tietojen avulla voidaan tarkistaa haavoittuvuuksia ja virheiden käsittelyä, mikä on tärkeää etenkin Power Pagesin sisältävissä ratkaisuissa.

Vain tarvittavan koodin kirjoittaminen

Koodin määrää vähentämällä voidaan vähentää myös mahdollisia tietoturvavikoja. Käytä uudelleen koodia ja kirjastoja, jotka ovat jo käytössä ja jotka ovat käyneet läpi tietoturvatarkistukset , koodin kopioinnin sijaan. Avoimen lähdekoodin ohjelmiston havaitseminen sekä version, haavoittuvuuden ja juridisten velvoitteiden tarkistaminen. Tämä on otettava huomioon, sillä käytössä on enenevä määrä avoimen lähdekoodin Power Platform -resursseja. Tästä on keskusteltava mahdollisuuksien mukaan suunnitteluvaiheessa, jottei ongelmia nouse esiin viime hetkillä.

Kehittäjäympäristöjen suojaaminen

Paljastuminen on estettävä suojaamalla kehittäjien työasemat on suojattava vahvalla verkon ja käyttäjätietojen hallinnalla. Suojauspäivityksiä on ehdottomasti käytettävä, ja se on varmistettava.

Myös lähdekoodivarasto on suojattava . Koodisäilöjen käyttöoikeudet kannattaa myöntää vain tarpeen mukaan ja hyökkäyksiä voi välttää vähentämällä mahdollisuuksien mukaan altistumista haavoittuvuuksille. Tarkista koodi perusteellisesti tietoturvahaavoittuvuuksien varalta. Sitä varten voidaan käyttää käyttöoikeusryhmiä ja toteuttaa liiketoimintaperusteisiin perustuva hyväksyntäprosessi.

Koodin turvallinen käyttöönotto

Pelkkä koodin suojaaminen ei riitä. Jos suoritetaan haavoittuvissa putkissa, suojaustoimet ovat turhia ja puutteellisia. Koonti- ja julkaisuympäristöt on myös suojattava , koska haluat estää haitallisia toimijoita suorittamasta haitallista koodia putkessasi.

Ajantasaisen luettelon ylläpitäminen jokaisesta sovelluksen integroidusta komponentista

Jokainen sovellukseen integrointi komponentti kasvattaa hyökkäyspinta-alaa. Näistä komponenteista on muodostettava luettelo, sillä se mahdollistaa asianmukaisen vastuullisen ja ilmoittamisen, kun uusia komponentteja lisätään tai niitä päivitetään. Säännöllisin väliajoin on tarkistettava, että luettelotiedosto vastaa koontiprosessin sisältöä. Tämä auttaa varmistamaan, ettei uusiin komponentteihin ole lisätty odottamatta takaportteja tai muita haittaohjelmia.

Käyttöönotoissa suositellaan käytettäväksi Power Platformin putkia. Putkia voi laajentaa GitHub Actionsin avulla. Jos käytät GitHub-työnkulkuja, mieluiten Microsoft luodut tehtävät. Tehtävät on myös tarkistettava, sillä ne suoritetaan putken suojauskontekstissa.

Palvelun päänimen käyttämiseen käyttöönotossa kannattaa perehtyä.

Tuotantovaihe

Tuotantovaihe on viimeinen vastuullinen mahdollisuus korjata tietoturva-aukot. Tuotantoon julkaistu näköistiedosto on kirjattava muistiin.

Artefaktien versiointitietojen säilyttäminen

Kaikki käyttöönotetut resurssit ja niiden versiot on kirjattava luetteloon. Näistä tiedoista on hyötyä tapausta selvitettäessä, ongelmia korjattaessa ja palautettaessa järjestelmää toimivaan tilaan. Versioituja resursseja voidaan myös verrat julkaistuihin CVE (Common Vulnerabilities and Exposures) -ilmoituksiin. Nämä vertailut kannattaa tehdä automatisoidusti.

Hätäkorjaukset

Automaattisen putkirakenteen pitäisi olla riittävän joustava, että se tukee sekä tavallista käyttöönottoa että hätäkäyttöönottoa. Tämä joustavuus on tärkeää, sillä se tukee nopeita ja vastuullisia suojauskorjauksia.

Julkaisuun liittyy tyypillisesti useita hyväksyntäportteja. Suojauskorjausten nopeuttamista varten kannattaa harkita hätäprosessin luontia. Tähän prosessiin voi liittyä tiimien välistä viestintää. Putken on mahdollistettava nopea eteenpäin siirtävät että peruuttavat käyttöönotot, jotka ottavat huomioon suojauskorjaukset, kriittiset ohjelmistovirheet ja säännöllisen käyttöönottoelinkaaren ulkopuolella tapahtuvat koodipäivitykset.

Muistiinpano

Suojauskorjaukset on aina priorisoitava riippumatta siitä, mikä olisi helpointa. Suojauskorjaus ei saa sisältää regressiota tai ohjelmistovirhettä. Jos korjaus halutaan siirtää nopeasti hätäputken läpi, on harkittava huolellisesti, mitkä automaattisesti testit voidaan ohittaa. Kunkin testin arvon ja sen suorittamiseen kuluvan ajan painoarvo on arvioitava. Yksikkötestit valmistuvat yleensä nopeasti, kun taas integrointitestien ja koko prosessin kattavien testien suorittaminen voi kestää pitkään.

Ympäristöjen pitäminen erillisinä

Tuotannon tietoja ei saa käyttää alemman tason ympäristöissä**, koska kyseisissä ympäristöissä ei ehkä käytetä yhtä tiukkaa suojauksen hallintaa kuin tuotantoympäristössä. Yhteyden muodostamista ei-tuotantoympäristöstä tuotantotietokantaan on vältettävä samoin kuin ei-tuotantoympäristön komponenttien yhdistämistä tuotannon verkkoihin.

Etenevän julkistamisen käyttäminen

Etenevän julkistamisen avulla ominaisuuksia voidaan julkaista käyttäjien alijoukolle valittujen ehtojen perusteella. Mahdollisten ongelmien vaikutus rajoittuu tällä tavoin kyseisiin käyttäjiin. Tämä menetelmä on yleinen riskien lieventämisstrategia, sillä se pienentää vaikutusaluetta. Ominaisuuden kehittyessä ja luottamuksen suojauksen varmistuksiin kasvaessa se voidaan vähitellen julkaista laajemmalle käyttäjäjoukolle.

Ylläpitovaihe

Tämän vaiheen tavoite on varmistaa, ettei suojauksen tilanne heikkene ajan mittaan. SDLC on jatkuva ja ketterä prosessi. Edellisessä vaiheissa käsitellyt käsitteet koskevat tätä vaihetta, sillä vaatimukset muuttuvat ajan mittaan.

Jatkuva parantaminen. Ohjelmistokehitysprosessin suojausta on arvioitava ja parannettava jatkuvasti ottamalla huomioon koodin arvioinnit, palaute, opitut seikat ja kehittyvät uhkat sekä Power Platformin mahdollistamat uudet ominaisuudet.

Poista käytöstä vanhat omaisuuserät , jotka ovat vanhentuneita tai joita ei enää käytetä. Tämä pienentää sovelluksen kokoa.

Ylläpito sisältää myös tapausten korjaukset. Jos tuotannossa havaitaan ongelmia, ne on integroitava nopeasti takaisin prosessiin siten, etteivät ne toistu.

Suojauksen koodauskäytäntöjen jatkuva parantaminen auttaa pysymään ajan tasalla uhkakuvista.

Microsoft Power Platformin SDL

Power Platform perustuu suojatun suunnittelun kulttuuriin ja menetelmiin. Sekä kulttuuria että menetelmiä vahvistetaan Microsoft jatkuvasti alan johtavilla tietoturvakehityksen elinkaari - (SDL) ja uhkamallinnuskäytännöillä .

Tehokas uhkien mallinnuksen tarkistusprosessi varmistaa, että uhat tunnistetaan suunnitteluvaiheessa, niitä lievennetään ja että varmistetaan, että niitä on lievennetty.

Uhkien mallinnus tekee jatkuvasti arvioita, joiden perusteella se kattaa kaikki palveluiden muutokset, jotka on julkaistu. STRIDE-mallin tuella on helpompaa käsitellä epävarman suunnittelun tavallisimpia ongelmia.

MicrosoftSDL vastaa OWASP Software Assurance Maturity Model (SAMM) -mallia . Molemmat rakentuvat lähtökohdalle, että turvallinen suunnittelu on olennainen osa verkkosovellusten suojauksessa. Lisätietoja on kohdassa Kymmenen merkittävintä OWASP-riskiä: lieventäminen Power Platformissa.

Power Platform – avustaminen

Microsoft Security Development Lifecycle (SDL) suosittelee suojattuja käytäntöjä, joita voit soveltaa kehityksen elinkaareen. Lisätietoja on kohdassa Microsoft Tietoturvakehityksen elinkaari.

Defender for DevOps- ja SAST (Static Application Security Testing) -työkalut sisältävät GitHubiin suojauksen lisäsetuksiin ja Azure DevOpsiin. Nämä työkalut voivat auttaa seuraamaan organisaation tietoturvapisteitä.

Ratkaisun tarkistustoiminnon avulla voi tehdä monipuolisen staattisen analyysin, jossa ratkaisun käyttöä verrataan parhaiden käytäntöjen mukaisiin sääntöihin. Tällä tavoin ongelmalliset kohdat havaitaan nopeasti. Lisätietoja on kohdassa Ratkaisujen tarkistaminen ratkaisun tarkistustoiminnon avulla.

Suojauksen tarkistusluettelo

Katso lisätietoja suositusten kokoelmasta.

Tietoturvan tarkistuslista