<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>ABAC &#8211; Smals Research</title>
	<atom:link href="https://www.smalsresearch.be/tag/abac/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.smalsresearch.be</link>
	<description></description>
	<lastBuildDate>Thu, 26 Mar 2026 13:27:15 +0000</lastBuildDate>
	<language>en-GB</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>

<image>
	<url>https://www.smalsresearch.be/wp-content/uploads/2026/01/cropped-cropped-Smals_Research-32x32.png</url>
	<title>ABAC &#8211; Smals Research</title>
	<link>https://www.smalsresearch.be</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Vertrouwelijkheidslabels om gevoelige gegevens beter te beschermen</title>
		<link>https://www.smalsresearch.be/vertrouwelijkheidslabels-om-gevoelige-gegevens-beter-te-beschermen/</link>
		
		<dc:creator><![CDATA[Fabien A. P. Petitcolas]]></dc:creator>
		<pubDate>Tue, 21 Jan 2025 10:00:00 +0000</pubDate>
				<category><![CDATA[[NL]]]></category>
		<category><![CDATA[Blog post]]></category>
		<category><![CDATA[ABAC]]></category>
		<category><![CDATA[access control]]></category>
		<category><![CDATA[classification]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[STANAG]]></category>
		<category><![CDATA[standards]]></category>
		<guid isPermaLink="false">/?p=21702</guid>

					<description><![CDATA[In dit artikel leggen we de voordelen van vertrouwelijkheidslabels uit en bekijken we twee gerelateerde standaardisatieovereenkomsten.]]></description>
										<content:encoded><![CDATA[
<p><a href="/etiquettes-de-confidentialite-pour-mieux-proteger-les-donnees-sensibles/"><em>Version française</em></a></p>



<p>Oorzaken van datalekken en veiligheidsincidenten zijn onder andere het per ongeluk delen of verkeerd gebruiken van gevoelige gegevens door een bediende of onderaannemer, of opzettelijke diefstal van gegevens door een kwaadwillige insider voor persoonlijk gebruik. Spijtig genoeg zijn veel gebruikelijke methodes en aanpakken niet ontworpen tegen dergelijke schendingen door gebruikers die a priori betrouwbaar lijken. De efficiëntste technieken zijn nog steeds voorbehouden aan zeer specifieke sectoren.</p>



<p>Het probleem bestaat echter al langer. In bepaalde kritische domeinen zoals de staatsveiligheid is het een gekend probleem. Sinds de jaren 70 inspireerde het model Bell-LaPadula<a href="#_ftn1" id="_ftnref1"><sup>1</sup></a> de compartimentering van informaticasystemen in geïsoleerde beveiligingsdomeinen. Een organisatie kan bijvoorbeeld fysiek gescheiden systemen invoeren: een verbonden met internet voor gegevens zonder specifiek vertrouwelijkheidsniveau en een voor elke van de vertrouwelijkheidsniveaus van de organisatie zoals “beperkt”, “vertrouwelijk” of “geheim”. Daarbovenop komen vaak klassieke mechanismes zoals het gebruik van vercijferde bestandssystemen, de blokkering&nbsp;– of zelfs verwijdering&nbsp;– van USB-poorten, de beperking van copy/pasten in software, maar ook de controle van alle gegevens die circuleren op het informaticanetwerk zodat gevoelige of vertrouwelijke gegevens kunnen opgespoord worden.</p>



<p>Om gegevens van een niveau naar een ander over te brengen kan deze organisatie een beroep doen op gespecialiseerde <em>IT gateways</em> bij de bescherming van de gegevens. Deze veronderstellen dat elk gegeven, alsook de gebruiker of de dienst van het domein dat deze gegevens verstuurt, eerst wordt gekoppeld aan een vertrouwelijkheidslabel waarmee beslist wordt of de gegevens al dan niet doorgestuurd kunnen worden. Informatiebescherming gebeurt met andere woorden op het vlak van de data-objecten zelf in plaats van op het vlak van domeinen die aangemaakt werden met gescheiden informaticanetwerken (die soms ontoegankelijk zijn en leiden tot stoelendansen).</p>



<h1 class="wp-block-heading">Vertrouwelijkheidslabels</h1>



<p>De vertrouwelijkheidslabels zijn een manier om verschillende beveiligingskenmerken<a href="#_ftn2" id="_ftnref2"><sup>2</sup></a> te linken aan een specifiek object. Deze vertrouwelijkheidslabels kunnen eender welke nuttige informatie bevatten om beslissingen te nemen op het vlak van veiligheid en worden <em>a priori</em> beschouwd als correct wanneer een veiligheidsbeslissing zich daarop baseert. Er bestaan twee belangrijke manieren om een vertrouwelijkheidslabel toe te kennen aan een data-object:</p>



<ul class="wp-block-list">
<li>De veiligheidseigenschappen baseren op de oorsprong van de informatie aanwezig in het data-object. Dat is de eenvoudigste methode op voorwaarde dat de oorsprong van de informatie traceerbaar is.</li>



<li>De eigenlijke inhoud van het data-object evalueren om de beveiligingskenmerken te bepalen. In een volgend artikel bekijken we hoe deze toewijzing min of meer automatisch kan verlopen.</li>
</ul>



<p>Het gebruik van vertrouwelijkheidslabels heeft verschillende beperkingen. Bij de onderlinge verbinding van twee systemen op verschillende veiligheidsniveaus moet er rekening gehouden worden met het risico op verkeerde labeling van de objecten (bv. gebruikersfout, misbruikt of gecompromitteerd systeem, enz.). Bovendien:</p>



<ul class="wp-block-list">
<li>Weerspiegelt een vertrouwelijkheidslabel de beschermingsvereisten en de voorwaarden voor vrijgave van een object bij de creatie van dit label. De update van deze laatste vereist manuele handelingen die strikte beheersprocessen moeten volgen.</li>



<li>De labeling volgt niet altijd correct de objecten, zelfs binnen eenzelfde organisatie.</li>



<li>Omwille van subjectieve interpretaties van het veiligheidsbeleid kunnen de auteurs van de objecten verschillende vertrouwelijkheidslabels plakken op objecten met gelijkaardige inhoud. Dit kan leiden tot situaties waarin sterk gelijkende gegevens verschillende beveiligingsniveaus kunnen hebben.</li>
</ul>



<p>De labeling van de informatie leidt dus tot minstens twee belangrijke uitdagingen. De eerste betreft het bestaan van een syntaxis en een gemeenschappelijke interpretatie van de labels&nbsp;– dit wil zeggen tussen de systemen die informatie willen uitwisselen. De andere is de definitie van een mechanisme waarmee deze labels verbonden kunnen worden aan de objecten waarbij de integriteit van deze link verzekerd wordt.</p>



<h1 class="wp-block-heading">Gestandaardiseerd mechanisme</h1>



<p>In 2010 heeft de onderzoeksgroep voor domeinoverschrijdende veiligheidsoplossingen van de Organisatie voor Wetenschap en Technologie van de NAVO een <a href="https://www.sto.nato.int/publications/_layouts/WordViewer.aspx?id=/publications/STO%20Meeting%20Proceedings/RTO-MP-IST-091/MP-IST-091-22.doc">voorstel</a> gepubliceerd voor XLM-specificatie voor labeling en verbinding van metagegevens. Dit werk werd later verwerkt in twee “<em><u>stan</u>dardisation <u>ag</u>reements</em>” of “STANAG”.</p>



<p>Het eerste <em>standardisation agreement</em> “STANAG 4774&nbsp;– Confidentiality Metadata Label Syntax”&nbsp;<a href="#_ref1">[1]</a> is een XML-schema dat gebruikt kan worden om een vertrouwelijkheidslabel weer te geven en om machtigingen van de entity’s te beschrijven. Het voorziet formaten en een gemeenschappelijke XML-gebaseerde syntaxis voor veiligheidspolicy’s en vertrouwelijkheidsmetadata. Het kan toegepast worden tussen entity’s die bestuurd worden door verschillende, identieke policy’s of zonder veiligheidspolicy. Om de interoperabiliteit tussen verschillende systemen te verzekeren bestaan er profielen voor verschillende objecttypes: SOAP, REST, Office Open XML, enz.</p>



<p>In het kader van deze <em>standardisation agreement</em> werd de syntaxis van de vertrouwelijkheidslabels ontworpen om gebruikt te worden zodat een of meerdere elementen van metadata bepaald kunnen worden aangezien deze elementen op hun beurt verbonden worden aan de data-objecten. De vertrouwelijkheidslabels kunnen drie soorten metadata specificeren:</p>



<ul class="wp-block-list">
<li>vertrouwelijkheidslabel door de auteur toegekend aan de informatie.</li>



<li>vertrouwelijkheidslabel in een verschillende policy die vergelijkbaar is met het vertrouwelijkheidslabel van de auteur.</li>



<li>vertrouwelijkheidslabel verbonden aan de beschrijvende metadata van het beveiligde object.</li>
</ul>



<p>Het tweede <em>standardisation agreement</em> “STANAG 4778 – Metadata Binding Mechanism” <a href="#_ref2">[2]</a> is een XML-schema dat gebruikt kan worden om willekeurige metadata (ook metadata die de syntaxis van het vertrouwelijkheidslabel gebruiken) te verbinden aan de data-objecten tijdens hun levenscyclus en doorheen verschillende organisaties. De link tussen de metadata en het object zorgt er bijvoorbeeld voor dat de oorsprong van de gegevens bewezen, hun integriteit en authenticiteit gecontroleerd, hun vertrouwelijkheid en informatiebescherming verzekerd, een controleketen opgezet en informatiedeling vergemakkelijkt kan worden. Deze manier van veiligheidsdata en -metadata met elkaar te verbinden doet denken aan de methoden voor het beheer van digitale beperkingen die gebruikt worden om onder andere digitale auteursrechtelijke werken te beschermen.</p>



<p>De STANAG-norm 4778 laat verschillende aanpakken toe:</p>



<ul class="wp-block-list">
<li><strong>Losse verbinding</strong>: de metadata worden opgeslagen in een aparte structuur van het data-object, en de twee worden aan elkaar gekoppeld via een referentie.</li>



<li><strong>Integration</strong>: de verbinding wordt geïntegreerd in het data-object en de verbinding bevat een referentie naar het data-object.</li>



<li><strong>Encapsulation</strong>: het data-object en de metadata worden ingekapseld in de verbinding en weergegeven door een nieuw samengesteld data-object.</li>
</ul>



<p>Aangezien een data-object samengesteld kan zijn (bv.: een document met meerdere hoofdstukken en paragrafen) en elk subelement zijn eigen metadata kan hebben, geeft de STANAG-norm 4778 na te leven regels om de metadata van een samengesteld object goed te interpreteren.</p>



<p>De norm definieert tot slot de syntaxis en de semantiek van het verbindingsmechanisme tussen metadata en data-objecten. Verbindingsprofielen beschrijven hoe het verbindingsmechanisme van de metadata toegepast moet worden op gegevensformaten en specifieke protocollen (bv.: Microsoft Word-documenten, JPEG-afbeeldingen), maar de norm laat niet toe datastromen zoals video’s en audiostreams te verwerken.</p>



<p>Merk tot slot op dat de verbinding bepaald door de norm niet sterk is en dat er een digitale handtekening toegevoegd moet worden die de data-objecten en metadata dekt, bijvoorbeeld door de W3C-aanbeveling “<a href="https://www.w3.org/TR/xmldsig-core2/">XML Signature Syntax and Processing</a> te gebruiken”.</p>



<h1 class="wp-block-heading">Conclusies</h1>



<p>De toepassing van vertrouwelijkheidslabels zoals die bepaald worden in de STANAG-normen 4474 en 4778 is een belangrijk element bij de invoering van een datagecentraliseerde veiligheidsstrategie. Het gebruik van deze labels in een attribuut-gebaseerd toegangscontrolesysteem (bv.: die XACML-policy’s gebruiken) biedt een dynamische en contextuele toegangscontrole waardoor organisaties een uiterst flexibele en efficiënte naleving van de reglementering kunnen bekomen.</p>



<p>Er bestaan veel overwegingen wat betreft de invoering van dergelijke systemen en in het bijzonder de evaluatie van de gevoeligheid van de gegevens waar de labeling van afhangt. Daar komen we op terug in een volgend artikel.</p>



<p>Bibliografische referenties</p>



<p><a name="_ref1">[1]</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <em>Confidentiality metadata label syntax</em>, NATO standard ADat-4774, Edition A Version 1, NATO Standardisation Office (NSO), 20 december 2017.</p>



<p><a name="_ref2">[2]</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <em>Metadata binding mechanism</em>, NATO standard ADatP-4778, Edition A Version 1, NATO Standardisation Office (NSO), 26 oktober 2018.</p>



<h1 class="wp-block-heading">Noten</h1>



<p><a href="#_ftnref1" id="_ftn1"><sup>1</sup></a> &nbsp; Een model ontwikkeld in de jaren 70 om het meerlagig veiligheidsbeleid te formaliseren van de defensieafdeling van de Verenigde Staten. Het model wordt gekenmerkt door het aforisme “naar boven schrijven, naar beneden lezen” (het omgekeerde is verboden).</p>



<p><a href="#_ftnref2" id="_ftn2"><sup>2</sup></a> &nbsp; De kenmerken zijn paren van het type (<em>sleutel</em>, <em>waarde</em>) die gelinkt kunnen worden aan eender welke entiteit: data-object, gebruiker, omgeving, enz.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p><em>Dit is een ingezonden bijdrage van Fabien A. P. Petitcolas, IT-beveiligingsspecialist bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.</em></p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>Étiquettes de confidentialité pour mieux protéger les données sensibles</title>
		<link>https://www.smalsresearch.be/etiquettes-de-confidentialite-pour-mieux-proteger-les-donnees-sensibles/</link>
					<comments>https://www.smalsresearch.be/etiquettes-de-confidentialite-pour-mieux-proteger-les-donnees-sensibles/#comments</comments>
		
		<dc:creator><![CDATA[Fabien A. P. Petitcolas]]></dc:creator>
		<pubDate>Tue, 21 Jan 2025 10:00:00 +0000</pubDate>
				<category><![CDATA[[FR]]]></category>
		<category><![CDATA[Blog post]]></category>
		<category><![CDATA[ABAC]]></category>
		<category><![CDATA[access control]]></category>
		<category><![CDATA[classification]]></category>
		<category><![CDATA[Security]]></category>
		<category><![CDATA[STANAG]]></category>
		<category><![CDATA[standards]]></category>
		<guid isPermaLink="false">/?p=21700</guid>

					<description><![CDATA[Dans cet article nous expliquons les avantages des étiquettes de confidentialité et examinons deux accords de normalisation afférents.]]></description>
										<content:encoded><![CDATA[
<p><em><a href="/vertrouwelijkheidslabels-om-gevoelige-gegevens-beter-te-beschermen/">Nederlandstalige versie</a></em></p>



<p>Parmi les causes de violations de données et d’incidents de sécurité on trouve le partage accidentel ou la mauvaise manipulation d’informations sensibles par un employé ou un sous-traitant, ou le vol délibéré de données par un initié malveillant à des fins personnelles. Malheureusement beaucoup de méthodes et d’approches habituelles ne sont pas conçues pour se protéger de telles violations par des utilisateurs a priori de confiance et les techniques les plus efficaces sont encore réservées à des secteurs très spécifiques.</p>



<p>Le problème n’est pourtant pas nouveau. Il est en fait bien connu dans certains domaines critiques comme la sécurité d’un pays. Dès les années 1970, le modèle de Bell-LaPadula<a href="#_ftn1" id="_ftnref1"><sup>1</sup></a> inspirait la compartimentalisation des systèmes informatiques en domaines de sécurité isolés. Par exemple une organisation peut mettre en œuvre des systèmes séparés physiquement&nbsp;: l’un, connecté à Internet, pour les informations sans niveau de confidentialité particulier et un pour chacun des niveaux de confidentialité de l’organisation comme par exemple «&nbsp;restreint,&nbsp;» «&nbsp;confidentiel,&nbsp;» ou «&nbsp;secret.&nbsp;» À cela sont souvent ajoutés des mécanismes classiques comme l’utilisation de systèmes de fichiers chiffrés, le blocage –&nbsp;voire le retrait&nbsp;– de ports USB, la restriction des fonctionnalités de copier/coller dans les logiciels, mais aussi l’inspection de toutes les données circulant sur le réseau informatique afin de détecter la présence éventuelle de données sensibles ou confidentielles.</p>



<p>Afin de transférer des informations d’un niveau à un autre cette organisation peut avoir recours à des passerelles informatiques spécialisées dans la protection des données. Celles-ci supposent que chaque donnée, ainsi que l’utilisateur ou le service du domaine envoyant ces données, sont d’abord liés à une étiquette de confidentialité permettant de décider si les données peuvent être transmises ou pas. En d’autres termes, la protection de l’information se fait au niveau des objets de données eux-mêmes plutôt qu’au niveau des domaines créés avec des réseaux informatiques séparés (parfois imperméables et conduisant à des processus de chaises tournantes).</p>



<h1 class="wp-block-heading">Étiquettes de confidentialité</h1>



<p>Les étiquettes de confidentialité sont des moyens d’associer différents attributs<a href="#_ftn2" id="_ftnref2"><sup>2</sup></a> de sécurité à un objet particulier. Ces étiquettes de confidentialité peuvent contenir n’importe quelles informations utiles pour prendre des décisions de sécurité et sont a priori considérées comme correctes lorsqu’une décision de sécurité se base dessus. Il existe deux manières principales d’assigner une étiquette de confidentialité à un objet de données&nbsp;:</p>



<ul class="wp-block-list">
<li>Baser les propriétés de sécurité sur l’origine de l’information présente dans l’objet de données. C’est la méthode la plus simple, pour autant que l’origine de l’information puisse être tracée.</li>



<li>Évaluer le contenu même de l’objet de données afin de déterminer les attributs de sécurité. Nous verrons dans un prochain article comment cette assignation peut être faite de manière plus ou moins automatique.</li>
</ul>



<p>L’utilisation d’étiquettes de confidentialité présente différentes limites. Lors de l’interconnexion de deux systèmes de niveaux de sécurité différents, il faut tenir compte du risque de mauvais étiquetage des objets (p. ex., erreur de l’utilisateur, détournement ou compromission du système, etc.). De plus&nbsp;:</p>



<ul class="wp-block-list">
<li>Une étiquette de confidentialité reflète les exigences de protection et les conditions de libération d’un objet au moment de la création de cette étiquette. La mise à jour de cette dernière requiert des opérations manuelles qui doivent suivre des processus de gestion stricts.</li>



<li>L’étiquetage ne voyage pas toujours correctement avec les objets, même au sein de la même organisation.</li>



<li>En raison d’interprétations subjectives de la politique de sécurité, les auteurs des objets peuvent apposer des étiquettes de confidentialité différentes pour des objets au contenu similaire. Cela peut conduire à des situations où des données très similaires peuvent avoir des niveaux de protection différents.</li>
</ul>



<p>L’étiquetage de l’information introduit donc au moins deux défis importants. Le premier concerne l’existence d’une syntaxe et d’une interprétation commune des étiquettes&nbsp;– c’est à dire entre les systèmes souhaitant échanger des informations. L’autre est la définition d’un mécanisme permettant de lier ces étiquettes aux objets tout en assurant l’intégrité de ce lien.</p>



<h1 class="wp-block-heading">Mécanisme standardisé</h1>



<p>En 2010, le groupe de recherche sur les solutions de sécurité inter-domaines de l’Organisation pour la science et la technologie de l’OTAN a publié une <a href="https://www.sto.nato.int/publications/_layouts/WordViewer.aspx?id=/publications/STO%20Meeting%20Proceedings/RTO-MP-IST-091/MP-IST-091-22.doc&amp;Source=https%3A%2F%2Fwww%2Esto%2Enato%2Eint%2Fpublications%2FSTO%2520Meeting%2520Proceedings%2FForms%2FMeeting%2520Proceedings%2520Document%2520Set%2Fdocsethomepage%2Easpx%3FID%3D36396%26FolderCTID%3D0x0120D5200078F9E87043356C409A0D30823AFA16F602008CF184CAB7588E468F5E9FA364E05BA5%26List%3D7e2cc123%2D6186%2D4c30%2D8082%2D1ba072228ca7%26RootFolder%3Dhttps%253A%252F%252Fwww%252Esto%252Enato%252Eint%252Fpublications%252FSTO%2520Meeting%2520Proceedings%252FRTO%252DMP%252DIST%252D091&amp;DefaultItemOpen=1&amp;DefaultItemOpen=1">proposition</a> de spécification XML pour l’étiquetage et la liaison des métadonnées. Ce travail a ensuite été développé dans deux accords de normalisation («&nbsp;<em><u>stan</u>dardisation <u>ag</u>reement</em>&nbsp;» ou «&nbsp;STANAG&nbsp;»).</p>



<p>Le premier accord de normalisation, le «&nbsp;STANAG 4774&nbsp;– Confidentiality Metadata Label Syntax&nbsp;»&nbsp;<a href="#_ref1">[1]</a> est un schéma XML qui peut être utilisé pour représenter une étiquette de confidentialité ainsi que pour décrire les habilitations des entités. Il fournit des formats et une syntaxe commune basée sur le langage XML pour les politiques de sécurité et les métadonnées de confidentialité. Il peut s’appliquer entre des entités gouvernées par des politiques différentes, identiques, ou sans politique de sécurité. Afin d’assurer l’interopérabilité entre différents systèmes, des profils existent pour différents types d’objets&nbsp;: SOAP, REST, Office Open XML, etc.</p>



<p>Dans le cadre de cet accord de normalisation, la syntaxe des étiquettes de confidentialité a été conçue pour être utilisée afin de définir un ou plusieurs éléments de métadonnées, ces éléments de métadonnées étant à leur tour liés à des objets de données. Les étiquettes de confidentialité peuvent spécifier trois types de métadonnées&nbsp;:</p>



<ul class="wp-block-list">
<li>étiquette de confidentialité attribuée à l’information par l’auteur.</li>



<li>étiquette de confidentialité dans une politique différente qui est équivalente à l’étiquette de confidentialité de l’auteur.</li>



<li>étiquette de confidentialité associée aux métadonnées descriptives de l’objet protégé.</li>
</ul>



<p>Le deuxième accord de normalisation, le «&nbsp;STANAG 4778&nbsp;– Metadata Binding Mechanism&nbsp;»&nbsp;<a href="#_ref2">[2]</a> est un schéma XML qui peut être utilisé pour lier des métadonnées arbitraires (y compris des métadonnées qui utilisent la syntaxe de l’étiquette de confidentialité) à des objets de données, au cours de la vie de ceux-ci et à travers différentes organisations. Le lien entre les métadonnées et l’objet permet par exemple de prouver l’origine des informations, de vérifier leur intégrité et authenticité, d’assurer la confidentialité et la protection de l’information, de mettre en place une chaîne de contrôle, et de faciliter le partage de l’information. Cette façon de lier données et métadonnées de sécurité n’est pas sans rappeler les méthodes de gestion numérique des restrictions utilisées pour protéger notamment les œuvres numérisées bénéficiant d’un droit d’auteur.</p>



<p>La norme STANAG&nbsp;4778 autorise différentes approches&nbsp;:</p>



<ul class="wp-block-list">
<li><strong>Liaison détachée</strong>&nbsp;: les métadonnées sont stockées dans une structure distincte de l’objet de données, et les deux sont liés par référence.</li>



<li><strong>Intégration</strong>&nbsp;: la liaison est intégrée dans l’objet de données et la liaison contient une référence à l’objet de données.</li>



<li><strong>Encapsulation</strong>&nbsp;: l’objet de données et les métadonnées sont encapsulés dans la liaison et représentés par un nouvel objet de données composite.</li>
</ul>



<p>Puisqu’un objet de données peut être composite (p. ex., un document avec plusieurs chapitres et paragraphes), et que chaque sous-élément peut avoir ses propres métadonnées, la norme STANAG&nbsp;4778 donne les règles à respecter afin de bien interpréter les métadonnées d’un objet composite.</p>



<p>Enfin la norme définit la syntaxe et la sémantique du mécanisme de liaison entre métadonnées et objets de données. Des profils de liaison décrivent comment appliquer le mécanisme de liaison des métadonnées à des formats de données et à des protocoles spécifiques (p. ex., documents Microsoft Word, images JPEG), mais la norme ne permet pas de traiter les flux de données comme les vidéos et les transmissions sonores.</p>



<p>Notons enfin que la liaison définie par la norme n’est pas forte et il faut ajouter une signature numérique couvrant l’objets de données et les métadonnées, par exemple en utilisant la recommandation du W3C «&nbsp;<a href="https://www.w3.org/TR/xmldsig-core2/">XML Signature Syntax and Processing</a>.&nbsp;»</p>



<h1 class="wp-block-heading">Conclusions</h1>



<p>L’application d’étiquettes de confidentialité comme, par exemple, celles définies dans les normes STANAG&nbsp;4474 et 4778 est un élément important de la mise en œuvre d’une stratégie de sécurité centrée sur les données. L’utilisation de ces étiquettes dans un système de contrôle d’accès basé sur les attributs (par ex. utilisant des politiques XACML) offre un contrôle d’accès dynamique et contextuel, permettant aux organisations d’atteindre avec une grande flexibilité, une conformité réglementaire efficace.</p>



<p>Il existe de nombreuses considérations liées à la mise en œuvre de tels systèmes et notamment l’évaluation de la sensibilité des informations dont dépend l’étiquetage. Cela sera l’objet d’un prochain article.</p>



<h1 class="wp-block-heading">Références</h1>



<p><a name="_ref1">[1]</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <em>Confidentiality metadata label syntax</em>, NATO standard ADat-4774, Edition A Version 1, NATO Standardisation Office (NSO), 20 décembre 2017.</p>



<p><a name="_ref2">[2]</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <em>Metadata binding mechanism</em>, NATO standard ADatP-4778, Edition A Version 1, NATO Standardisation Office (NSO), 26 octobre 2018.</p>



<h1 class="wp-block-heading">Notes</h1>



<p><a href="#_ftnref1" id="_ftn1"><sup>1</sup></a> &nbsp; Un modèle développé dans les années 1970 afin de formaliser la politique de sécurité multi-niveau du département de la défense des États-Unis. Le modèle est caractérisé par l’aphorisme «&nbsp;écrire vers le haut, lire vers le bas&nbsp;» (l’inverse étant interdit).</p>



<p><a href="#_ftnref2" id="_ftn2"><sup>2</sup></a> &nbsp; Les attributs sont des paires de type (<em>nom</em>, <em>valeur</em>)&nbsp;qui peuvent être associées à n’importe quelle entité&nbsp;: objet de données, utilisateur, environnement, etc.</p>



<hr class="wp-block-separator has-alpha-channel-opacity"/>



<p><em>Ce post est une contribution individuelle de Fabien A. P. Petitcolas, spécialisé en sécurité informatique chez Smals Research. Cet article est écrit en son nom propre et n&#8217;impacte en rien le point de vue de Smals.</em></p>
]]></content:encoded>
					
					<wfw:commentRss>https://www.smalsresearch.be/etiquettes-de-confidentialite-pour-mieux-proteger-les-donnees-sensibles/feed/</wfw:commentRss>
			<slash:comments>2</slash:comments>
		
		
			</item>
	</channel>
</rss>
