Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1307625553.1259830700679.JavaMail.jira@brutus>
Date: Thu, 3 Dec 2009 08:58:20 +0000 (UTC)
From: "linden lin (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-2014) [DAC] Audit
In-Reply-To: <2107153691.1259263359602.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-2014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785232#action_12785232 ] 

linden lin commented on HBASE-2014:
-----------------------------------

Audit is always for regulatory needs. How to secure auditing data as evidence and if there is enough detail to trace the source and problem is the key point I think. If the auditing data can deliver to target in time, it will better.

>From regulatory compliant needs, it not only needs to acquire all events on the table, but also needs to collect the necessary events from the cluster, such as server offline information, and some necessary information (metadata and status at that time) to analyze the event. Thus, third-part software can get the detailed event in time for monitoring, content inspection or policy enforcement in the company.


> [DAC] Audit
> -----------
>
>                 Key: HBASE-2014
>                 URL: https://issues.apache.org/jira/browse/HBASE-2014
>             Project: Hadoop HBase
>          Issue Type: Sub-task
>            Reporter: Andrew Purtell
>            Assignee: Andrew Purtell
>             Fix For: 0.22.0
>
>
> Audit: Important actions taken by subjects should be logged for accountability, a chronological record which enables the full reconstruction and examination of a sequence of events, e.g. schema changes or data mutations. Logging activity should be protected from all subjects except for a restricted set with administrative privilege, perhaps to only a single super-user.
> Support dynamic scaling transparently and support multi-tenant. Acquire enough detail and support streamline auditing in time. Should be configurable on a per-table basis to avoid this overhead where it is not wanted.
> Consider logging audit trails to an HBase table (bigtable type schemas are natural for this) and also external options with Java library support - syslog, etc., or maybe commons-logging is sufficient and punt to administrator to set up appropriate commons-logging/log4j configurations for their needs.
> Consider integration with Scribe (http://developers.facebook.com/scribe/) or Chukwa (http://wiki.apache.org/hadoop/Chukwa).
> * Session information (Required)
> ** Client, server, When, How, Where.
> * Command information (Required)
> ** Command detail and intent
> ** Command result and why
> ** Data event (input and output interested data, depends on predefined policy) 
> *** Metadata, data detail, session identity and command identity, data direction, etc.
> ** Command Counts (optional)
> *** Execution duration
> *** Response/request data amount
> *** Resource usage
> * Node status
> ** Node resource counts
> ** Session status
> ** Abnormal events (Required)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.