Dela via

Metodtips för säkerhet för Information Protection

  • Artikel

Viktigt

Versioner av Microsoft Rights Management Service SDK som släpptes före mars 2020 är inaktuella. program som använder tidigare versioner måste uppdateras för att använda versionen från mars 2020. Fullständig information finns i utfasningsmeddelandet.

Inga ytterligare förbättringar planeras för Microsoft Rights Management Service SDK. Vi rekommenderar starkt att du använder Microsoft Information Protection SDK för klassificerings-, märknings- och skyddstjänster.

Information Protection Software Development Kits (SDK:er) ger ett robust system för publicering och användning av skyddad information av alla typer. För att hjälpa ett system att vara så starkt som möjligt måste informationsskyddsaktiverade program skapas med bästa praxis. Program delar ansvaret för att upprätthålla säkerheten i det här ekosystemet. Identifiering av säkerhetsrisker och åtgärder för att lösa riskerna som introducerats under programutvecklingen hjälper att minimera risken för en mindre säker programvaruimplementering.

Den här informationen kompletterar det juridiska avtal som måste signeras för att få digitala certifikat för program som använder SDK:erna.

Ämnen som inte omfattas

Även om följande ämnen är viktiga saker att tänka på när du skapar en utvecklingsmiljö och säkra program, är de utanför omfånget för den här artikeln:

  • Processhantering av programutveckling – Konfigurationshantering, skydd av källkod, minimera åtkomst till felkod och tilldela prioritet till buggar. För vissa kunder är en säkrare programvaruutvecklingsprocess av största vikt för dem. Vissa kunder kan även ange en utvecklingsprocess.
  • Vanliga kodningsfel – Information för att undvika buffertöverskridanden. Vi rekommenderar den senaste versionen av Writing Secure Code av Michael Howard och David LeBlanc (Microsoft Press, 2002) för att se över de här generiska hoten och åtgärderna.
  • Social engineering – Innehåller information om processuella och strukturella skyddsåtgärder, för att skydda kod mot utnyttjande av utvecklare eller andra inom tillverkarens organisation.
  • Fysisk säkerhet – innehåller information om hur du skyddar åtkomst till din kodbas och signeringscertifikat.
  • Etablering eller distribution av förhandsversioner av programvara – innehåller information om hur du distribuerar betaversioner av programvaran.
  • Nätverkshantering – innehåller information om system för intrångsidentifiering på dina fysiska nätverk.

Hotmodeller och åtgärder

Ägare av digital information behöver kunna utvärdera de miljöer där deras tillgångar dekrypteras. En beskrivning av minimisäkerhetsstandarder ger informationsägare ett ramverk för att förstå och bedöma programsäkerhetsnivån.

Vissa branscher, som myndigheter och hälsovård, har certifierings- och ackrediteringsprocesser och standarder som kan omfatta din produkt. Att uppfylla dessa minsta säkerhetsrekommendationer ersätter inte dina kunders unika ackrediteringsbehov. Men syftet med säkerhetsstandarderna är att hjälpa dig att förbereda för aktuella och framtida kundkrav och alla investeringar som görs tidigt i utvecklingscykeln hjälper din programvara. Dessa riktlinjer är rekommendationer, inte ett formellt Microsoft-certifieringsprogram.

Det finns flera huvudkategorier med säkerhetssårbarheter i ett Rights Management-system, inklusive:

  • Läckage – Information visas på obehöriga platser.
  • Skada – Programvara eller data ändras på ett otillåtet sätt.
  • Denial – En beräkningsresurs är inte tillgänglig för användning.

De här ämnena fokuserar primärt på läckageproblem. Integriteten för ett API-system beror på dess förmåga att över tid skydda information, vilket endast ger åtkomst till utsedda entiteter. De här avsnitten behandlar även problem med skador. Förnekelseproblem täcks inte.

Microsoft testar eller granskar inte testresultat som rör uppfyllande av minimistandarden. Partnern ansvarar för att säkerställa att miniminormerna uppfylls. Microsoft tillhandahåller två ytterligare rekommendationsnivåer för att hjälpa att åtgärda vanliga hot. I allmänhet är dessa förslag additiva. Om du till exempel uppfyller rekommenderade rekommendationer förutsätter vi att du har uppfyllt minimikraven, om tillämpligt, om inget annat anges.

Standardnivå Description
Minsta standard Ett program som hanterar skyddad information måste uppfylla minimistandarden innan det kan signeras med det produktionscertifikat som tas emot från Microsoft. Partner använder vanligtvis certifikatet för produktionshierarkin vid tidpunkten för den slutliga versionen av programvaran. En partners egna interna tester används för att kontrollera om programmet uppfyller den här minimistandarden. Att uppfylla minimistandarden är inte och bör inte tolkas som en säkerhetsgaranti från Microsoft. Microsoft testar eller granskar inte testresultat som rör uppfyllande av minimistandarden. Partnern ansvarar för att säkerställa att minimivärdet uppfylls.
Rekommenderad standard Rekommenderade riktlinjer visar både en sökväg till förbättrad programsäkerhet och ger en indikation på hur SDK:t kan utvecklas när fler säkerhetskriterier implementeras. Leverantörer kan skilja sina program genom att bygga till den här högre nivån av säkerhetsriktlinjer.
Önskad standard Den här standarden är den högsta säkerhetskategorin som för närvarande definieras. Leverantörer som utvecklar program som marknadsförs med hög säkerhet bör sträva efter den här standarden. Program som följer den här standarden är sannolikt minst sårbara för angrepp.

Skadlig programvara

Microsoft har definierat minsta nödvändiga standarder som ditt program behöver uppfylla för att skydda innehåll från skadlig programvara.

Importera skadlig programvara med hjälp av adresstabeller

SDK:n för informationsskydd stöder inte kodändring vid körning eller ändring av importadresstabellen (IAT). En importadress-tabell skapas för varje DLL som läses in i processutrymmet. Den anger adresserna för alla funktioner som ditt program importerar. Ett vanligt angrepp är att ändra IAT-posterna inom ett program för att, exempelvis, peka mot skadlig programvara. SDK stoppar programmet när det identifierar den här typen av angrepp.

Minsta standard

  • Du kan inte ändra importadresstabellen i programprocessen under körningen. Ditt program anger många av de funktioner som anropas vid körning med hjälp av adresstabeller. Dessa tabeller kan inte ändras under eller efter körningen. Den här begränsningen innebär bland annat att du inte kan utföra kodprofilering i ett program som signerats med hjälp av produktionscertifikatet.
  • Du kan inte anropa funktionen DebugBreak inifrån någon DLL som anges i manifestet.
  • Du kan inte anropa LoadLibrary med flaggan DONT_RESOLVE_DLL_REFERENCES inställd. Den här flaggan säger till inläsaren att hoppa över att binda till de importerade modulerna, vilket ändrar importadress-tabellen.
  • Du kan inte ändra fördröjd inläsning genom att göra körnings- eller efterföljande ändringar i /DELAYLOAD-länkväxeln.
  • Du kan inte ändra fördröjd inläsning genom att ange din egen version av hjälpfunktionen Delayimp.lib.
  • Du kan inte ta bort moduler som fördröjs av autentiserade moduler, medan SDK-miljön för informationsskydd finns.
  • Du kan inte använda /DELAY:UNLOAD länkväxeln för att aktivera avlastning av fördröjda moduler.

Felaktig tolkning av licensrättigheter

Om ditt program inte tolkar och framtvingar de rättigheter som uttrycks i SDK-utfärdandelicensen korrekt kan du göra information tillgänglig på ett sätt som informationsägaren inte hade för avsikt att göra. När ett program till exempel tillåter en användare att spara okrypterad information i nya medier, när utfärdandelicensen endast ger rätt att visa informationen.

Azure Information Protection (AIP)

Informationsskyddssystemet organiserar rättigheter några grupper. Mer information finns i Konfigurera användningsrättigheter för Azure Information Protection.

Med AIP kan en användare antingen dekryptera information eller inte. Informationen har inget inbyggt skydd. Om en användare har rätt att dekryptera tillåter API:et det. Programmet ansvarar för att hantera eller skydda informationen när den är klar. Ett program ansvarar för att hantera sin miljö och sitt gränssnitt för att förhindra obehörig användning av information. Du kan till exempel inaktivera knapparna Skriv ut och kopiera om en licens endast ger VIEW-behörigheten. Din testsvit bör verifiera att ditt program agerar på rätt sätt för alla licensrättigheter som den känner igen.

Minsta standard

  • Kundimplementeringen av XrML v.1.2-rättigheter bör överensstämmande med definitionerna av dessa rättigheter, enligt beskrivningen i XrML-specifikationerna, som är tillgängliga på XrML-webbplatsen (http://www.xrml.org). Alla rättigheter som är specifika för ditt program måste definieras för alla entiteter som har intresse av ditt program.
  • Testpaketet och testprocessen bör kontrollera att programmet körs korrekt mot de rättigheter som programmet stöder. Den bör också kontrollera att den inte agerar på rättigheter som inte stöds.
  • Om du skapar ett publiceringsprogram måste du göra information tillgänglig som förklarar de inbyggda rättigheter som används. Detta inkluderar de som stöds och inte stöds av publiceringsprogrammet och hur dessa rättigheter ska tolkas. Dessutom bör användargränssnittet klargöra för slutanvändaren konsekvenserna av varje rättighet som beviljas eller nekas en enskild informationsmängd.
  • Alla rättigheter som abstraheras, genom inkludering i nya rättigheter som implementeras av ett program, måste mappas till den nya terminologin. En ny rättighet vid namn ANSVARIG kan exempelvis inkludera SKRIV UT, KOPIERA och REDIGERA som abstraherade rättigheter.

Ingen just nu.

Önskad standard

Ingen just nu.

Nästa steg

Metodtips för att implementera program med hjälp av AIP SDK innehåller följande artiklar: