Share via

Aanbevolen beveiligingsprocedures voor Information Protection

  • Artikel

Belangrijk

Versies van de Microsoft Rights Management Service SDK die vóór maart 2020 zijn uitgebracht, worden afgeschaft; toepassingen die eerdere versies gebruiken, moeten worden bijgewerkt voor gebruik van de release van maart 2020. Zie de afschaffingsmelding voor meer informatie.

Er zijn geen verdere verbeteringen gepland voor de Microsoft Rights Management Service SDK. We raden u ten zeerste aan de Microsoft Information Protection SDK te gebruiken voor classificatie-, label- en beveiligingsservices.

Information Protection SDK's (Software Development Kits) bieden een robuust systeem voor het publiceren en gebruiken van beveiligde informatie van alle typen. Om een systeem zo sterk mogelijk te laten zijn, moeten toepassingen met gegevensbeveiliging worden gebouwd met behulp van best practices. Toepassingen delen de verantwoordelijkheid bij het onderhouden van de beveiliging van dit ecosysteem. Als u tijdens het ontwikkelen van toepassingen de beveiligingsrisico's identificeert en oplossingen voor deze risico's biedt, verkleint u de kans op een minder veilige software-implementatie.

Deze informatie vormt een aanvulling op de wettelijke overeenkomst die moet worden ondertekend, om digitale certificaten te verkrijgen voor toepassingen die gebruikmaken van de SDK's.

Onderwerpen die niet worden behandeld

Hoewel de volgende onderwerpen belangrijke overwegingen zijn voor het maken van een ontwikkelomgeving en veilige toepassingen, vallen ze buiten het bereik van dit artikel:

  • Procesbeheer voor softwareontwikkeling : configuratiebeheer, het beveiligen van broncode, het minimaliseren van toegang tot foutopsporingscode en het toewijzen van prioriteit aan fouten. Voor sommige klanten is het belangrijk om een veiliger softwareontwikkelingsproces te hebben. Andere klanten schrijven zelfs een ontwikkelingsproces voor.
  • Veelvoorkomende coderingsfouten : informatie voor het voorkomen van bufferoverschrijdingen. U wordt aangeraden de meest recente versie van 'Writing Secure Code' van Michael Howard en David LeBlanc (Microsoft Press, 2002) te lezen voor meer informatie over deze algemene bedreigingen en oplossingen.
  • Social engineering — Bevat informatie over procedurele en structurele waarborgen, om code te beschermen tegen exploitatie door ontwikkelaars of anderen binnen de organisatie van de fabrikant.
  • Fysieke beveiliging: bevat informatie over het vergrendelen van toegang tot uw codebasis en het ondertekenen van certificaten.
  • Implementatie of distributie van prereleasesoftware: bevat informatie over het distribueren van uw bètasoftware.
  • Netwerkbeheer: bevat informatie over systemen voor het detecteren van indringers in uw fysieke netwerken.

Bedreigingsmodellen en -oplossingen

Eigenaren van digitale informatie hebben de mogelijkheid nodig om de omgevingen te evalueren waarin hun assets worden ontsleuteld. Een verklaring van minimale beveiligingsstandaarden biedt informatie-eigenaren een framework voor het begrijpen en beoordelen van het beveiligingsniveau van de toepassingen.

In bepaalde branches, zoals de overheid en gezondheidszorg, zijn er certificerings- en accrediteringsprocessen en -standaarden die van toepassing kunnen zijn op uw product. Het voldoen aan deze minimale beveiligingsaanaanveling is geen vervanging voor de unieke accreditatiebehoeften van uw klanten. Het doel van de beveiligingsstandaarden is echter u te helpen bij de voorbereiding voor huidige en toekomstige klantvereisten. Van alle investeringen die u vroeg in het ontwikkelingsproces doet, zal uw toepassing profiteren. Deze richtlijnen zijn aanbevelingen, geen formeel Microsoft-certificeringsprogramma.

Er zijn verschillende categorieën met beveiligingsproblemen in een Rights Management Services-systeem, waaronder:

  • Lekken: gegevens worden weergegeven op onbevoegde locaties.
  • Beschadiging: softwareprogramma's of gegevens worden op niet-toegestane manier gewijzigd.
  • Denial : een computingresource is niet beschikbaar voor gebruik.

In deze onderwerpen wordt hoofdzakelijk ingegaan op problemen met betrekking tot het lekken van gegevens. De integriteit van een API-systeem is afhankelijk van de mogelijkheid om in de loop van de tijd informatie te beveiligen, waardoor alleen toegang tot aangewezen entiteiten mogelijk is. In deze onderwerpen komen ook problemen met betrekking tot beschadigingen aan bod. Denial-problemen worden niet behandeld.

Microsoft test of beoordeelt geen testresultaten met betrekking tot het voldoen aan de minimumstandaard. De partner is verantwoordelijk voor het waarborgen van de minimumnormen. Microsoft biedt twee extra niveaus van aanbevelingen om algemene bedreigingen te beperken. Over het algemeen zijn deze suggesties additief. Als u bijvoorbeeld aan aanbevelingen van voorkeur voldoet, wordt ervan uitgegaan dat u, indien van toepassing, aan de minimumstandaarden hebt voldaan, tenzij anders is opgegeven.

Standaardniveau Description
Minimumstandaard Een toepassing die beveiligde informatie verwerkt, moet voldoen aan de minimale standaard, voordat deze kan worden ondertekend met het productiecertificaat dat is ontvangen van Microsoft. Partners gebruiken over het algemeen het certificaat voor de productiehiërarchie, op het moment van definitieve release van de software. De eigen interne tests van een partner worden gebruikt om te controleren of de toepassing voldoet aan deze minimumstandaard. Het voldoen aan de minimale standaard is niet en mag niet worden geïnterpreteerd als een garantie voor beveiliging door Microsoft. Microsoft test of beoordeelt geen testresultaten met betrekking tot het voldoen aan de minimumstandaard. De partner is verantwoordelijk voor het waarborgen van het minimum.
Aanbevolen standaard Aanbevolen richtlijnen brengen beide een pad naar verbeterde toepassingsbeveiliging in kaart en geven een indicatie van hoe de SDK zich kan ontwikkelen naarmate er meer beveiligingscriteria worden geïmplementeerd. Leveranciers kunnen hun toepassingen onderscheiden door te bouwen aan dit hogere beveiligingsniveau.
Voorkeursstandaard Deze standaard is de hoogste beveiligingscategorie die momenteel is gedefinieerd. Leveranciers die toepassingen ontwikkelen met het label 'streng beveiligd' moeten deze standaard nastreven. Toepassingen die aan deze standaard voldoen, zijn waarschijnlijk het minst kwetsbaar voor aanvallen.

Schadelijke software

Microsoft heeft minimaal vereiste standaarden gedefinieerd waaraan uw toepassing moet voldoen om uw inhoud tegen schadelijke software te beveiligen.

Schadelijke software importeren met behulp van adrestabellen

De Information Protection SDK biedt geen ondersteuning voor codewijziging tijdens runtime of wijziging van de IAT (Import Address Table). Voor elk DLL-bestand dat in uw procesruimte wordt geladen, wordt een IAT gemaakt. Hiermee worden de adressen aangegeven van alle functies die met uw toepassing worden geïmporteerd. Een veelvoorkomende aanval is het wijzigen van de IAT-vermeldingen binnen een toepassing, zodat deze bijvoorbeeld verwijzen naar schadelijke software. De SDK stopt de toepassing wanneer dit type aanval wordt gedetecteerd.

Minimumstandaard

  • U kunt de importadrestabel tijdens de uitvoering niet wijzigen in het toepassingsproces. Uw toepassing geeft veel van de functies op die tijdens runtime worden aangeroepen met behulp van adrestabellen. Deze tabellen kunnen niet worden gewijzigd tijdens of na runtime. Deze beperking betekent onder andere dat u geen codeprofilering kunt uitvoeren op een toepassing die is ondertekend met behulp van het productiecertificaat.
  • U kunt de debugBreak-functie niet aanroepen vanuit een DLL die is opgegeven in het manifest.
  • U kunt LoadLibrary niet aanroepen met de DONT_RESOLVE_DLL_REFERENCES vlagset. Met deze vlag wordt aan het laadprogramma doorgegeven dat de binding met de geïmporteerde modules moet worden overslagen, waardoor de IAT wordt gewijzigd.
  • U kunt vertraagd laden niet wijzigen door runtime- of volgende wijzigingen aan te brengen in de linkerswitch /DELAYLOAD.
  • U kunt vertraagd laden niet wijzigen door uw eigen versie van de helperfunctie Delayimp.lib op te geven.
  • U kunt modules die vertraagd worden geladen door geverifieerde modules niet verwijderen, terwijl de omgeving van de Information Protection SDK bestaat.
  • U kunt de /DELAY:UNLOAD linkerschakelaar niet gebruiken om het lossen van vertraagde modules mogelijk te maken.

Licentierechten onjuist interpreteren

Als uw toepassing de rechten die zijn uitgedrukt in de SDK-uitgiftelicentie niet correct interpreteert en afdwingt, kunt u informatie beschikbaar maken op manieren waarop de eigenaar van de informatie niet van plan was. Wanneer een toepassing bijvoorbeeld toestaat dat een gebruiker niet-versleutelde gegevens opslaat op nieuwe media, verleent de uitgiftelicentie alleen het recht om de informatie weer te geven.

Azure Information Protection (AIP)

Het informatiebeveiligingssysteem organiseert enkele groeperingen. Zie Gebruiksrechten configureren voor Azure Information Protection voor meer informatie.

Met AIP kan een gebruiker gegevens ontsleutelen of niet. De informatie heeft geen inherente beveiliging. Als een gebruiker het recht heeft om te ontsleutelen, staat de API deze toe. De toepassing is verantwoordelijk voor het beheren of beveiligen van die informatie nadat deze duidelijk is. Een toepassing is verantwoordelijk voor het beheren van de omgeving en interface om onbevoegd gebruik van informatie te voorkomen. Als u bijvoorbeeld de knoppen Afdrukken en Kopiëren uitschakelt als een licentie alleen het VIEW-recht verleent. In uw testpakket moet worden gecontroleerd of uw toepassing juist omgaat met alle licentierechten die worden herkend.

Minimumstandaard

  • De implementatie van XrML v.1.2-rechten moet consistent zijn met de definities van deze rechten, zoals beschreven in de XrML-specificaties, die beschikbaar zijn op de XrML-website (http://www.xrml.org). Alle rechten die specifiek van toepassing zijn op uw toepassing, moeten worden gedefinieerd voor alle entiteiten die belang hebben bij uw toepassing.
  • Uw testsuite en testproces moeten controleren of uw toepassing correct wordt uitgevoerd op basis van de rechten die de toepassing ondersteunt. Er moet ook worden gecontroleerd of er geen actie wordt uitgevoerd op niet-ondersteunde rechten.
  • Als u een publicatietoepassing bouwt, moet u informatie beschikbaar maken die uitleg geeft over de intrinsieke rechten die worden gebruikt. Dit omvat degenen die wel en niet worden ondersteund door de publicatietoepassing en hoe deze rechten moeten worden geïnterpreteerd. Daarnaast moet in de gebruikersinterface duidelijk voor de eindgebruiker zijn aangegeven wat de gevolgen zijn van elk recht dat aan afzonderlijke gegevens wordt verleend of geweigerd.
  • Alle rechten die worden geabstraheerd door opname in nieuwe rechten die door een toepassing worden geïmplementeerd, moeten worden toegewezen aan de nieuwe terminologie. Bijvoorbeeld: het nieuwe recht MANAGER kan bijvoorbeeld als onttrokken rechten de rechten AFDRUKKEN, KOPIËREN en BEWERKEN bevatten.

Geen op dit moment.

Voorkeursstandaard

Geen op dit moment.

Volgende stappen

Aanbevolen procedures voor het implementeren van toepassingen met behulp van de AIP SDK bevatten de volgende artikelen: