You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Rob Tallis (JIRA)" <ji...@apache.org> on 2013/05/15 11:07:15 UTC

[jira] [Updated] (ACCUMULO-1070) Improve the auditing messages that are generated from the server.

     [ 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