accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Tallis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-1070) Improve the auditing messages that are generated from the server.
Date Wed, 15 May 2013 09:07:15 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rob Tallis updated ACCUMULO-1070:
---------------------------------

    Attachment: accumulo-1070-3.patch

Here is accumulo-1070-3.patch - it doesn't depend on patches 1 or 2.

I haven't finished yet but it's got to the point where I need some feedback to see if I'm
going about this the right way. (though I think it's still useful in it's current form)

You'll see that I've created a separate Audit logger with separate config, I think where I
have made changes to the audit messages, the original messages weren't getting output anywhere
anyway.

The range of actions I'm auditing isn't quite complete and there's a few things I still need
to look at. Here I've just gone for the easy ones by hanging off AuditedSecurityOperation.java;


What I wasn't sure about was, with one audit log per node, is what messages would come out
where, and would we get duplicates. Having briefly tried it, it seems random to me, and it
does generate dupes (which isn't unexpected I guess); not that it should present a massive
problem.

I've added in some tests using MAC and grepping the logs to check the messages are present,
it adds to the build time though.

I've looked at the previous comments about binary column names, I've left it for now, I'm
unsure what the impact would be. getTokenClassName - I couldn't see what it was telling me,
so left that out.

I've not updated any documentation, I'm unsure where it should go.

If this looks ok, I will later need to take a look at:
 - including the ip/fqdn of the user running the command
 - logging whether a scan returned results, or not, or even better the rowcount.
I'm unsure how to do these, so I'll park them for now.

Thanks, Rob
                
> Improve the auditing messages that are generated from the server.
> -----------------------------------------------------------------
>
>                 Key: ACCUMULO-1070
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-1070
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: master, tserver
>    Affects Versions: 1.4.2
>            Reporter: Philip Young
>            Assignee: Philip Young
>              Labels: patch, security
>             Fix For: 1.6.0
>
>         Attachments: accumulo-1070-1.patch, accumulo-1070-2.patch, accumulo-1070-3.patch
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> Auditing of all user interactions, including system administrators, is sometimes required
by a companies so that they can retrospectively audit user interactions after a security breach.
Currently, not all user operations on the Accumulo server are generating audit messages and
if they are, not in a consistent manner. 
> The audit created in the AuditedSecurityOperations class are not currently creating consistent
messages when an user passes the operation validation to when they fail the operation validation.
> Also, the Scan operations are not being audited and it would be very useful to know who
has run scans and what those scans were, by including: the principal user, the column families,
the ranges, etc.
>  
> I am intending to address both of these issues and submit a patch in the next week.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message