toegang weigeren tot server

[jokko]

Beste,

Bij een klant van ons hebben we een server staan die virtueel draait op ESXI 6.0.
De server is een Windows 2012 R2 64 bit in een domein.

Op deze server staat een share Directie.
De bedoeling is dat zelfs administrators niet op de server mogen inloggen.
Dit omdat ze anders ownership kunnen nemen van de share directie en nog de bestanden kunnen inzien.

Nu willen ze een administrator account die wel mag inloggen op de server en waarvan het wachtwoord bij niemand bekend is en in de kluis gaat.

Hoe kan ik het beste de toegang blokkeren voor alle anderen administrator accounts en ook zo dat zij dit niet meer aan kunnen passen ?

Zelf heb ik al met GPO's zitten kijken maar hier mee kwam ik niet echt verder.
Ook met delegation control kreeg ik het niet zo als het moest zijn.

Heeft iemand van jullie hier een mooie oplossing voor ?

[m3gA]

start run - lusrmgr.msc
Maak een nieuwe lokale user / domein user aan
Zet deze in de administrator groep
Haal alle andere administrators uit de administrator groep.

Maar hoe ga je deze server beheren / patchen etc?
En normaal vertrouw je je IT personeel en moet je er vanuit gaan dat ze niet gaan rondneuzen.

[u_nix_we_all]

Misschien eens kijken naar encryptie. Zo kun je de server gewoon beheren, alleen de files van Directie zijn encrypted en alleen zij hebben de key.

[downtime]

u_nix_we_all schreef op woensdag 20 juli 2016 @ 10:48:
Misschien eens kijken naar encryptie. Zo kun je de server gewoon beheren, alleen de files van Directie zijn encrypted en alleen zij hebben de key.

Zover ik weet biedt Windows daar niet echt fijne opties voor. BitLocker werkt op diskniveau. Iedereen met admin rechten die kan inloggen kan daar ook bij. EFS werkt op user niveau. Dus directieleden zouden elkaars bestanden ook niet kunnen lezen.

Voor dit soort situaties lijkt auditing mij de ideale manier. Wij doen dat hier soms ook met gevoelige data. Daar kunnen admins wel bij maar elke actie, zelfs browsen door de folder, wordt gelogd. Daar zit monitoring op zodat die logging meteen naar de securitymensen wordt gestuurd.

[jokko]

m3gA schreef op woensdag 20 juli 2016 @ 10:48:
start run - lusrmgr.msc
Maak een nieuwe lokale user / domein user aan
Zet deze in de administrator groep
Haal alle andere administrators uit de administrator groep.

Maar hoe ga je deze server beheren / patchen etc?
En normaal vertrouw je je IT personeel en moet je er vanuit gaan dat ze niet gaan rondneuzen.

Dat is een optie die ik ook had geprobeerd echter kunnen ze dan nog via vcenter console inloggen op de server.

Beheren / patchen doen we met de credentials van het enne admin account dat alleen bij ons en de directeur bekend mag zijn, dit doen wij met het pakket n-central van n-able.

Ons als IT beheerder vertrouwd hij wel alleen de mensen van zijn eigen IT afdeling niet vandaar deze actie.

[begintmeta]

m3gA schreef op woensdag 20 juli 2016 @ 10:48:
...
En normaal vertrouw je je IT personeel en moet je er vanuit gaan dat ze niet gaan rondneuzen.

Lijkt me vrij normaal ervoor te zorgen dat, mocht het nodig zijn, it-personeel niet kan rondneuzen (tenminste niet meer dan andere onbevoegden).

[ralpje]

Naast bovenstaande, houd ook rekening met (bijvoorbeeld) backup. Het account waar de backup onder uitgevoerd wordt zal toch ook op z'n minst leesrechten op de folder moeten hebben om de backup correcte kunnen uitvoeren. En de credentials van dat account zullen bekend moeten zijn bij de persoon die die backup beheert

[Meekoh]

Je zou eens kunnen kijken naar Custom Security Templates.
http://www.windows-server...m/security-templates.html
But then again de Admin kan die templates wel weer aanpassen.
Wat ook nog zou kunnen is ADRMS. Daarmee kun je beperken wie bij de files kan.
Maar ook hier geld dat je Admin zichzelf in de groepen kan gooien zodat hij toch weer toegang heeft.

Wat je echt zou moeten willen is Auditing.

[Oogje]

downtime schreef op woensdag 20 juli 2016 @ 10:54:
[...]

Zover ik weet biedt Windows daar niet echt fijne opties voor. BitLocker werkt op diskniveau. Iedereen met admin rechten die kan inloggen kan daar ook bij. EFS werkt op user niveau. Dus directieleden zouden elkaars bestanden ook niet kunnen lezen.

Voor dit soort situaties lijkt auditing mij de ideale manier. Wij doen dat hier soms ook met gevoelige data. Daar kunnen admins wel bij maar elke actie, zelfs browsen door de folder, wordt gelogd. Daar zit monitoring op zodat die logging meteen naar de securitymensen wordt gestuurd.

Zoiets lijkt me de beste insteek.

[Coach4All]

jokko schreef op woensdag 20 juli 2016 @ 10:59:
[...]


Ons als IT beheerder vertrouwd hij wel alleen de mensen van zijn eigen IT afdeling niet vandaar deze actie.

Waarom zitten ze er dan nog, als hij ze niet vertrouwt? Het zijn wel de mensen die met 1 druk op de knop mogelijk zijn bedrijf om zeep kunnen helpen.....

[jokko]

Coach4All schreef op woensdag 20 juli 2016 @ 11:06:
[...]


Waarom zitten ze er dan nog, als hij ze niet vertrouwt? Het zijn wel de mensen die met 1 druk op de knop mogelijk zijn bedrijf om zeep kunnen helpen.....

Niet vertrouwen is misschien niet goed verwoord, hij wil graag uitsluiten dat het kan gebeuren

[Silver7]

https://technet.microsoft...ry/cc780304(v=ws.10).aspx

Het kan wel maar dan moet je steeds user(s) toevoegen aan elke bestand.

[m3gA]

jokko schreef op woensdag 20 juli 2016 @ 10:59:
[...]


Dat is een optie die ik ook had geprobeerd echter kunnen ze dan nog via vcenter console inloggen op de server.

Beheren / patchen doen we met de credentials van het enne admin account dat alleen bij ons en de directeur bekend mag zijn, dit doen wij met het pakket n-central van n-able.

Ons als IT beheerder vertrouwd hij wel alleen de mensen van zijn eigen IT afdeling niet vandaar deze actie.

Via vcenter moet je ook inloggen als admin. Als je geen account hebt kom je er niet op.

[downtime]

Coach4All schreef op woensdag 20 juli 2016 @ 11:06:
[...]


Waarom zitten ze er dan nog, als hij ze niet vertrouwt? Het zijn wel de mensen die met 1 druk op de knop mogelijk zijn bedrijf om zeep kunnen helpen.....

Ik kan me voorstellen dat sommige bestanden voor eigen medewerkers veel interessanter zijn dan voor buitenstaanders. Denk aan HR-gerelateerde zaken.

[Verwijderd]

Heeft de directie al eens nagedacht over het volgende. Zolang iemand bij de backups, hardware, netwerk of de vm zelf kan is het bijna onmogelijk om een server inclusief data te beschermen.

Verder vraag ik me af hoe het aan de client side met security is gesteld

[Dirtyrockers]

is nooit 100% af te schermen voor de beheerders.

clone disk en koppel die aan een nieuwe server... tada!

of restore van backup naar een andere server?

Meestal heb je een geheimhoudingsverklaring getekend om dit soort dingen tegen te gaan.

[SpamLame]

ralpje schreef op woensdag 20 juli 2016 @ 11:00:
Naast bovenstaande, houd ook rekening met (bijvoorbeeld) backup. Het account waar de backup onder uitgevoerd wordt zal toch ook op z'n minst leesrechten op de folder moeten hebben om de backup correcte kunnen uitvoeren. En de credentials van dat account zullen bekend moeten zijn bij de persoon die die backup beheert

Hmm ja ja en dan kan de admin de files restoren naar een andere lokatie en de ACL omzeilen.
Was kennelijk niet de enige met deze gedachte.

[ Voor 5% gewijzigd door SpamLame op 20-07-2016 13:42 ]

[Craven]

u_nix_we_all schreef op woensdag 20 juli 2016 @ 10:48:
Misschien eens kijken naar encryptie. Zo kun je de server gewoon beheren, alleen de files van Directie zijn encrypted en alleen zij hebben de key.

^^ dit is de enige echte oplossing. De IT'ers zullen zichzelf altijd wel links of rechtsom toegang kunnen verlenen.

De machine moet je niet anders dan anders behandelen maar binnen de share moet je ervoor zorgen dat de bestanden encrypted zijn en dat alleen de directieleden deze kunnen decrypten.

Dan maakt fysieke toegang niet uit. Je moet misschien alleen nog even kijken naar compatibility met je backup methode.

[Verwijderd]

Ander idee:

Stel named accounts in en regel auditing op de folders.

[Question Mark]

Dan gooi ik als admin toch de auditlogs weg? Desnoods met een tijdelijk nieuw aangemaakt admin account...

Afgezien van de techniek, is dit meer een operationeel probleem. Het bedrijf/directie vertrouwt de beheerders niet.... Ook encryptie gaat dit niet oplossen. een beheerder kan altijd nog een password reset doen van een gebruiker die wel rechten op de share heeft, en als deze user aanloggen. Een admin kan er altijd bij....

[ Voor 31% gewijzigd door Question Mark op 20-07-2016 14:56 ]

[u_nix_we_all]

Question Mark schreef op woensdag 20 juli 2016 @ 14:55:
Dan gooi ik als admin toch de auditlogs weg? Desnoods met een tijdelijk nieuw aangemaakt admin account...

Afgezien van de techniek, is dit meer een operationeel probleem. Het bedrijf/directie vertrouwt de beheerders niet.... Ook encryptie gaat dit niet oplossen. een beheerder kan altijd nog een password reset doen van een gebruiker die wel rechten op de share heeft, en als deze user aanloggen. Een admin kan er altijd bij....

Je zult de key dan ook niet aan een gebruikersaccount moeten koppelen, maar bijv. op een USB-stick moeten opslaan.
VWB backups: gewoon de ge-encrypte bestanden backuppen zou dan voldoende moeten zijn.

[begintmeta]

Ik meende dat Windows de private key voor EFS versleutelt met het gebruikerswachtwoord, en dat het na een wachtwoordreset (door iemand anders dan de sleuteleigenaar) niet meer met het nieuwe wachtwoord zou kunnen worden ontsleuteld (zaak is dan natuurlijk wel om recovery agents te beperken), maar ik ben bepaald geen windows-expert.

[ Voor 7% gewijzigd door begintmeta op 20-07-2016 15:06 ]

[Onbekend]

jokko schreef op woensdag 20 juli 2016 @ 10:45:
Op deze server staat een share Directie.
De bedoeling is dat zelfs administrators niet op de server mogen inloggen.
Dit omdat ze anders ownership kunnen nemen van de share directie en nog de bestanden kunnen inzien.

[knip]

Heeft iemand van jullie hier een mooie oplossing voor ?

Laat de directie al hun belangrijke bestanden in een .rar-file plaatsen met een wachtwoord erop.
Iedereen kan dan gewoon de .rar-bestanden zien en backuppen, maar alleen de directie kent het wachtwoord om de bestanden zelf in te zien.

[begintmeta]

Sowieso is het trouwens verstandig om smartcards en dergelijke zaken te gebruiken in plaats van/toegevoegd aan wachtwoorden, ook in verband met keyloggers etc, ik weet niet of rar smartcard-support heeft.

[ Voor 16% gewijzigd door begintmeta op 20-07-2016 15:17 ]

[Blankinho]

Question Mark schreef op woensdag 20 juli 2016 @ 14:55:
Dan gooi ik als admin toch de auditlogs weg? Desnoods met een tijdelijk nieuw aangemaakt admin account...

Afgezien van de techniek, is dit meer een operationeel probleem. Het bedrijf/directie vertrouwt de beheerders niet.... Ook encryptie gaat dit niet oplossen. een beheerder kan altijd nog een password reset doen van een gebruiker die wel rechten op de share heeft, en als deze user aanloggen. Een admin kan er altijd bij....

Er werd hierboven ook gerefereerd dat deze audit logs naar een externe logging (bijv. splunk)van de security afdeling gingen. Het verwijderen van deze logs wordt ook weer gelogd dus is het wel erg onverstandig om dit allemaal te doen aangezien je dan meteen aan kunt tonen dat dit met opzet is gedaan...

Feit blijft wel dat er altijd een mogelijkheid is voor een persoon (IT-admin) binnen het netwerk. Het is inderdaad vooral een operationeel/procedureel probleem!

Mitigerende maatregelen zijn;
- Geheimhoudingsverklaringen,
- audit logs (Zowel in vmware als op de lokale servers kunnen er audits worden ingesteld)
- externe logging van de audit logs
- persoonlijke admin accounts
- een goede inventarisatie van wie op welke servers rechten moet hebben gebaseerd op functieprofiel (roles and responsibilities) Zowel in vmware als op de lokale servers kunnen er restricties worden ingesteld
- risico analyse voor dit scenario zodat dit ook als case kan gelden voor directie om businesscase te maken
- file encryptie (is dit werkbaar voor een gezamenlijk medium tussen directieleden?)

Beveiliging moet altijd bekeken worden vanuit het oogpunt; secure vs workable

Werkbaar is naar mijn idee alles behalve encryptie en zie je ook bij alle bedrijven terugkomen. Encryptie is zeker goed om te implementeren maar het beheer en de mogelijke gevolgen van verloren keys buiten het maken van backups is te complex.

[Standeman]

Onbekend schreef op woensdag 20 juli 2016 @ 15:09:
[...]


Laat de directie al hun belangrijke bestanden in een .rar-file plaatsen met een wachtwoord erop.
Iedereen kan dan gewoon de .rar-bestanden zien en backuppen, maar alleen de directie kent het wachtwoord om de bestanden zelf in te zien.

Moet je alleen wel even oppassen dat winrar bij het openen/uitpakken het bestand niet in tmp folder gooit

[synoniem]

In een vergelijkbare situatie heb ik dergelijke bestanden ondergebracht op een niet-Windows server maar ik weet niet of dat hier haalbaar zou zijn.

[jokko]

Bedankt voor alle reacties.
Ik heb het nu even tijdelijk opgelost met de oplossing van m3gA.

de punten van Blankinho ga ik ook opnemen met de directie om te bespreken wat de eisen van hun zijn en hoe belangrijk deze bestanden nu precies zijn.

[Onbekend]

Standeman schreef op woensdag 20 juli 2016 @ 15:18:
[...]

Moet je alleen wel even oppassen dat winrar bij het openen/uitpakken het bestand niet in tmp folder gooit

Daar heb je gelijk in. Maar haalt Winrar het bestand niet weg als hij weer wordt gesloten?
Maar ik denk overigens dat je zo'n type probleem waarbij tijdelijk een normaal leesbaar bestand wordt opgeslagen veel vaker voorkomt dan we denken.
Maar om dit probleem dan weer op te lossen, zou je natuurlijk elke gebruiker een eigen temp-map met bijbehorende rechten moeten geven. En die hoeft niet gebackupt te worden.

[downtime]

Onbekend schreef op woensdag 20 juli 2016 @ 17:52:
[...]

Maar om dit probleem dan weer op te lossen, zou je natuurlijk elke gebruiker een eigen temp-map met bijbehorende rechten moeten geven. En die hoeft niet gebackupt te worden.

Nooit afgevraagd waar C:\Users\<username>\AppData\Local\Temp toe dient? En waarom het onder Local en niet onder Roaming staat? En waarom de %TEMP% variabele naar die map wijst?

[StevenK]

Ik zou eerder voor die data een cloud oplossing zoeken, waarbij er shared storage is (of shared documents) waar alleen de directie toegang heeft. Dan elimineer je meteen het risico dat die lokale bestanden toch benaderd kunnen worden, want er zijn dan geen lokale bestanden.

[BCC]

"De cloud" is ook gewoon een server met een beheerder, dus dat lost hier niets op.

[downtime]

BCC schreef op woensdag 20 juli 2016 @ 19:21:
"De cloud" is ook gewoon een server met een beheerder, dus dat lost hier niets op.

Soms is dat een prima oplossing. In dit geval zijn er bestanden waarvan de directie het een probleem vindt dat eigen personeel dat kan zien, maar het minder een probleem vindt als een externe medewerker het kan zien.

Ik gok dat het gaat om salarisinformatie, personeelsdossiers, reorganisatieplannen, of andere zaken die voor interne mensen veel interessanter zijn dan voor een buitenstaander.

[Onbekend]

downtime schreef op woensdag 20 juli 2016 @ 18:06:
[...]

Nooit afgevraagd waar C:\Users\<username>\AppData\Local\Temp toe dient? En waarom het onder Local en niet onder Roaming staat? En waarom de %TEMP% variabele naar die map wijst?

Dat het van die gebruiker is, betekent niet dat anderen automatisch geen rechten daartoe hebben.
Als ik naar de eigenschappen van de "Temp"-map kijk, heeft standaard elke gebruiker leesrechten en de administrators zelfs ook nog schrijfrechten.
Dus die moet je actief verwijderen.

[StevenK]

BCC schreef op woensdag 20 juli 2016 @ 19:21:
"De cloud" is ook gewoon een server met een beheerder, dus dat lost hier niets op.

Maar bij de meeste cloud diensten heeft de eigen systeembeheerder niet voldoende rechten om zich toegang toe te eigenen tot bestanden.

[downtime]

Onbekend schreef op woensdag 20 juli 2016 @ 20:17:
[...]

Dat het van die gebruiker is, betekent niet dat anderen automatisch geen rechten daartoe hebben.
Als ik naar de eigenschappen van de "Temp"-map kijk, heeft standaard elke gebruiker leesrechten en de administrators zelfs ook nog schrijfrechten.
Dus die moet je actief verwijderen.

Niet bij mij. Ik zie System, Administrators en m'n eigen account met Full Control. Meer niet.

[rdvl]

Wij maken gebruik voor de directie van een product wat automatisch een map versleuteld en ontsleuteld.
Product is een USB stick met hierin een eigen processor en cryptomechanisme.

De map is versleuteld, maar zodra de USB Stick in de computer zit dan is de map vervolgens automatisch ontsleuteld. Back-up is ook geen probleem aangezien het gewoon Windows bestanden zijn, alleen zijn ze onleesbaar voor de gebruikers zonder stick.

[Onbekend]

downtime schreef op woensdag 20 juli 2016 @ 20:28:
[...]

Niet bij mij. Ik zie System, Administrators en m'n eigen account met Full Control. Meer niet.

Ik heb het even nagezocht, en in een domein is dat inderdaad het geval. Je moet alsnog actief alle administrators de toegang ontzeggen tot de temp-map.

[akimosan]

Onbekend schreef op zondag 24 juli 2016 @ 10:03:
[...]

Ik heb het even nagezocht, en in een domein is dat inderdaad het geval. Je moet alsnog actief alle administrators de toegang ontzeggen tot de temp-map.

En dan kunnen die Administrators alsnog "Take ownership" doen en vervolgens de permissies opnieuw zetten. Volgens mij blijven we in een kringetje draaien, lees even eerdere reacties voordat je zoiets zegt...

[Clueless]

Wellicht eens kijken naar een product als DESlock+? DESlock+ Folder Encryption

Wij kregen het toevallig om dat we bestaande ESET klanten zijn (DESlock+ Essential Edition). Er is ook een Personal Edition die gratis is als je het zelf eens wil testen.

[ Voor 13% gewijzigd door Clueless op 24-07-2016 15:39 . Reden: add personal edition ]

[Wim-Bart]

De enige echte oplossing is gewoon met rollen te werken en niet iedere beheerder domein admin/enterprise admin te maken. Dit werkt perfect en heb nog geen rare zaken gezien. Je kan daarna met GPO's de lokale Administrators Group vullen met beheerders welke alleen op deze server(s) kunnen inloggen.

Daarnaast kan je een AD groep maken waar je lid van moet zijn om ownership te krijgen van bestanden, beschikbaar voor selectief aantal beheerders. Tevens natuurlijk twee of zelfs drie accounts per beheerder:

1. Werk account zonder enige rechten voor beheer
2. Admin account voor de dagelijkse beheer werkzaamheden
3. Superadmin account, alleen nodig als je bijvoorbeeld een schema moet uitbreiden en dergelijke

Daarnaast auditing aanzetten op folders en rapportages maken, fileserver resource manager is hier perfect voor.

Overigens:

Allow logon locally: Administrators
Disable logon locally: Domain Admins

Zorgt er voor dat domain admins niet via console kunnen aanmelden.

En bovendien:
Administrator en Domain Administrator wachtwoorden horen altijd in een kluis te liggen en zijn bij niemand bekend (zetten met unattend.xml)
Altijd een tweede local Administrator account aanmaken (kan ook met unattend.xml)

[begintmeta]

akimosan schreef op zondag 24 juli 2016 @ 15:24:
[...]


En dan kunnen die Administrators alsnog "Take ownership" doen en vervolgens de permissies opnieuw zetten. Volgens mij blijven we in een kringetje draaien, lees even eerdere reacties voordat je zoiets zegt...

Hoe zit het met toegang tot de file encryption key? Is het niet zo dat bij een password reset de bestanden niet meer gedecrypt kunnen worden, omdat de encryption key van de user dan nog met het oorspronkelijke wachtwoord is versleuteld?

[downtime]

begintmeta schreef op maandag 25 juli 2016 @ 17:51:
[...]

Hoe zit het met toegang tot de file encryption key? Is het niet zo dat bij een password reset de bestanden niet meer gedecrypt kunnen worden, omdat de encryption key van de user dan nog met het oorspronkelijke wachtwoord is versleuteld?

Nee. Als je EFS encryptie bedoelt: Dat is niet aan het password gekoppeld maar aan een code die in het user deel van de registry staat. Nadeel is dat je wel backups van dat userprofile (of de encryptiekey zelf) moet maken.

[begintmeta]

downtime schreef op maandag 25 juli 2016 @ 18:41:
[...]

Nee. Als je EFS encryptie bedoelt: Dat is niet aan het password gekoppeld maar aan een code die in het user deel van de registry staat. Nadeel is dat je wel backups van dat userprofile (of de encryptiekey zelf) moet maken.

Hmm, ik meende dat de key waarmee de (symmetrische file encryption key wordt versleuteld door afhankelijk van wachtwoord van de user wordt versleuteld, denk op het verkeerde been gezet door 'You Cannot Access Protected Data After You Change Your Password' en 'The Encrypting File System'
'This problem occurs because the protected data is encrypted by using a hash that is based on your password.'
'- File encryption uses a symmetric key, which is then itself encrypted with the public key of a public key encryption pair. The related private key must be available in order for the file to be decrypted. This key pair is bound to a user identity and made available to the user who has possession of the user ID and password. If the private key is damaged or missing, even the user that encrypted the file cannot decrypt it. If a recovery agent exists, then the file may be recoverable. If key archival has been implemented, then the key may be recovered, and the file decrypted. If not, the file may be lost. EFS is an excellent file encryption system—there is no "back door."
- EFS keys are protected by the user's password. Any user who can obtain the user ID and password can log on as that user and decrypt that user's files. Therefore, a strong password policy as well as strong user education must be a component of each organization's security practices to ensure the protection of EFS-encrypted files.'

[downtime]

Ik heb jouw link bekeken en ik denk dat je gelijk hebt. Het is ook al zo lang geleden dat ik iets met EFS gedaan heb.

[TheVMaster]

Ik zeg Azure rights Management...

[Meekoh]

TheVMaster schreef op maandag 25 juli 2016 @ 20:17:
Ik zeg Azure rights Management...

Of de lokale variant, Active Directory Rights Management Services.

[TheVMaster]

Meekoh schreef op dinsdag 26 juli 2016 @ 11:38:
[...]

Of de lokale variant, Active Directory Rights Management Services.

Dat kan natuurlijk ook, maar Azure RMS is vele malen eenvoudiger te configureren, geen on-premises infra nodig, geen PKI etc...makkelijke keuze lijkt mij

[Wim-Bart]

TheVMaster schreef op dinsdag 26 juli 2016 @ 11:55:
[...]


Dat kan natuurlijk ook, maar Azure RMS is vele malen eenvoudiger te configureren, geen on-premises infra nodig, geen PKI etc...makkelijke keuze lijkt mij

Ja, maar een eigen PKI en dergelijke inrichten is gewoonweg wel leuk, inclusief enrolment policies voor onder andere EFS

[TheVMaster]

Wim-Bart schreef op dinsdag 26 juli 2016 @ 12:02:
[...]


Ja, maar een eigen PKI en dergelijke inrichten is gewoonweg wel leuk, inclusief enrolment policies voor onder andere EFS

Tja...ik ben dan ook een echte fan van EMS (waar Azure RMS onderdeel van is). Daarnaast is het inrichten van PKI vast leuk (alles opbouwen/inrichten is leuk, zolang het maar MS stuff is ), maar het moet ook onderhouden worden....je moet er kennis van hebben/opbouwen. Niet iedere organisatie heeft/wil dat, dan is Azure RMS wel een erg nette oplossing. Daarnaast zijn er nog veel meer voordelen te noemen, maar dat gaat te ver om die hier even te noemen...

[Wim-Bart]

TheVMaster schreef op dinsdag 26 juli 2016 @ 12:04:
[...]


Tja...ik ben dan ook een echte fan van EMS (waar Azure RMS onderdeel van is). Daarnaast is het inrichten van PKI vast leuk (alles opbouwen/inrichten is leuk, zolang het maar MS stuff is ), maar het moet ook onderhouden worden....je moet er kennis van hebben/opbouwen. Niet iedere organisatie heeft/wil dat, dan is Azure RMS wel een erg nette oplossing. Daarnaast zijn er nog veel meer voordelen te noemen, maar dat gaat te ver om die hier even te noemen...

Daarom heb je ook vitualisatie, zelf labjes bouwen en scenario's testen. Documenteren en product doorgronden Kant en klaar is makkelijk maar het is net zoals auto rijden, soms is het handig om te weten hoe je de olie moet verversen zonder naar de garage te moeten.

[TheVMaster]

Wim-Bart schreef op dinsdag 26 juli 2016 @ 12:08:
[...]


Daarom heb je ook vitualisatie, zelf labjes bouwen en scenario's testen. Documenteren en product doorgronden Kant en klaar is makkelijk maar het is net zoals auto rijden, soms is het handig om te weten hoe je de olie moet verversen zonder naar de garage te moeten.

Sure...sure....dan blijft het nog steeds als je het niet nodig hebt dan scheelt dat weer in beheerkosten etc. Daarbij is het delen van (versleutelde) documenten met personen 'buiten je organisatie' een stuk eenvoudiger met Azure RMS, dan met AD RMS en heb ik het nog niet gehad over de bekijken van documenten op mobiele devices (moet ik nog even doorgaan )....

Maar inderdaad iedere zichzelf respecterende IT-er moet zeker beschikken over een LAB om zaken te bouwen/testen etc.