Video Screencast Help

How to Secure data from SysAdmins?

Created: 20 Sep 2012 • Updated: 16 Oct 2012 | 15 comments
This issue has been solved. See solution.

Looking for information on how to secure data from the administrators of Enterprise Vault.  Is there a way to prevent evault administrators from searching specific mail?  Is their a way to encrypt data with a key?  Is there a way to put certain mail in an archive and prevent access to this?  Using an older version of Evault but willing to upgrade if its supported in newer versions.

Discussion Filed Under:

Comments 15 CommentsJump to latest comment

LCT's picture

Have a look at Roll Base Administration and also specify archive permissions to deny certain persions or groups acces to archives. You can do this via EVPM.

TonySterling's picture

Further to what LCT said, neither Power Admins or the Vault Service Account automatically have permission to search archives other than their own.  They either need permission granted on the archives or have permission inherited from the mailbox.

 

 

Jeff Shotton's picture

You might also want to look at switching auditing on, so an admin could not give themselves access, then search, and then remove that access.

http://www.symantec.com/docs/TECH49054

Also, there are ways that searches can be logged via webapp.ini

http://www.symantec.com/docs/TECH66548

see page 142 of the EV8 base admin guide (this still works in 9, but is not documented)

You would obviously have to stop the admin altering the logfiles created, and the webapp.ini file.

Regards,

Jeff

 

 

 

 

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

dmc123's picture

We are setup for journal archiving vs specific mailbox.  So its one general archive that all messages are in.  Although I know you can do roles, I'm asking about a way to guarantee an Admin can't assign them selves access.  The audit process allows for a check mechanism, but ideal is to prevent access vs report on unauthorized.

TonySterling's picture

You would have to secure the Vault Service Account and then set up a custom role in RBA that can't manage archive permissions.

You could then manually deny permission on the journal archives for the Admins.  A manual deny will override an automatically set permission.

Rob.Wilcox's picture

As a matter of interest, how are you securing the Exchange side of things?  I mean, a regular Exchange Admin *could* open a users mailbox, and read/edit/delete data.

John Santana's picture

Yes, this is what my CIO told my manager just recently, I overheard them :-\

so yes how can I do this in EV 8.0 SP4 ?

Kind regards,

John Santana
IT Professional

--------------------------------------------------

Please be nice to me as I'm newbie in this forum.

TonySterling's picture

So couple things for you.

First, here is an article about RBA to help you out with the roles bit.

https://www-secure.symantec.com/connect/articles/r...

For the permissions on the archives, it would be something like this technote, only using DenyAccess:

How to give permissions to an archive using Enterprise Vault Policy Manager (EVPM)

Article:TECH69114  |  Created: 2009-01-25  |  Updated: 2011-05-09  |  Article URL http://www.symantec.com/docs/TECH69114

So your script would look like this:

 

[Directory]
DirectoryComputerName = evdirectory
SiteName = evsite

[ArchivePermissions]
ArchiveName = ALL_MAILBOX
DenyAccess = read write, domain\adminusergroup
 

No one caveat, if your admin account is the same as your user account you will be blocked from your own archive so you will need to log in as the VSA and manually remove the Deny from the properties of the archives.

 

SOLUTION
John Santana's picture

Wow that does make sense Tony.

Many thanks for the quick reply !

Kind regards,

John Santana
IT Professional

--------------------------------------------------

Please be nice to me as I'm newbie in this forum.

Rob.Wilcox's picture

I second Tonys comment. In addition auditing, so admins can't change the perms without it being recorded. Then again they could maybe delete the audit records.. So you would need to prevent that in SQL too.

Like I asked though how are you securing Excange?

John Santana's picture

Yes, that does make sense Rob, as for the Exchange Server, well I do not implement very tight security because DOMAIN admin has the full rights to every settings and content of the Exchange Server.

Kind regards,

John Santana
IT Professional

--------------------------------------------------

Please be nice to me as I'm newbie in this forum.

Rob.Wilcox's picture

Hi John,

 

Okay so that's partly my point then ...  securing the 'estate' needs to focus not just on Enterprise Vault.  Particularly in your case since your organisation has changed the default Domain Admin permissions.  By default Domain Admins don't get access to the content of the Exchange Server - they can't login to 'just anyones' email.

 

However just because Exchange security isn't "perfect" doesn't mean your question is invalid ..  Put another way, your question IS valid - how could/should you secure Enterprise Vault?.  Hopefully we've given you the right ideas, of auditing, limiting who has access to the VSA login, and so on?

 

Hope that helps,

John Santana's picture

Yes that does make sense afterall Rob.

Thanks for the suggestion :-)

Kind regards,

John Santana
IT Professional

--------------------------------------------------

Please be nice to me as I'm newbie in this forum.

dmc123's picture

How do we secure exchange... unfortunately I don't have an answer for that one yet.  We are going through the same discussion on that system as well as others.  The premisions for that ability are limited to a few users and with tripwire type systems we can atleast track some of it, but yes we are struggling with the solution on that side as well.

 

For the other user that asked about securing the database, seperation of duties solves that problem to some degree.  With a DBA who is not an Exchange / Email Admin it would require assistance to purge informaiton.  So although a concern, less likely.  Especially when using auditing tools and logs that we could review if it was suspeected.