Importance of Data Auditing for providing maximum security:
As you may recall, the core problem addressed by Data Auditing is visibility into how users are accessing granular stored data. Data-at-rest typically falls into two categories: databases (structured data) or file servers (unstructured data). In databases, this means understanding how specific tables and columns are being accessed by users. In file servers, this means understanding how specific files on file-shares are being accessed by users.
A key criterion for evaluating Digital Asset Management systems is application depth and coverage. That is: how well they understand application access activity AND how broadly they are able to extend this understanding across various applications. Both are of key importance. Many auditing systems can do one or the other, but for an effective enterprise DAM, you want a combination of both. There are two architectural components that drive this: good parser capability and an abstract application model.
Parsers for Depth:
Say you want to audit access to tables and columns in an Oracle database. This will require your Digital Asset Management system to understand Oracle access activity–either over the network or by parsing its logs– (we will get into the specifics of monitoring alternatives in the next post on Monitoring) and break it up semantically into what I call “dimensions” of activity. Examples of dimensions could be: Who is the user, what commands are they issuing, what data assets are they touching, what was the result of this activity, which user host did they come from, what client application created this activity, the actual extent of data disclosure if there was one, etc. Unfortunately, the application transactional activity is not easy to translate into these dimensions. For example, SQL transactions or stored procedures in databases can be very complex and hard to translate into simple dimensions. The same goes for file servers where block-level application semantics makes it hard to keep the state of a session. In almost all cases, this requires a DAM system to develop significant application expertise and develop “expert” parsers that can understand transactions and sessions. Parsing is different from “pure” pattern matching – it requires a system to translate a log or activity into a semantic model driven by a protocol/grammar and associate the semantics with dimensions.
The specific words “select” don’t mean much – where they fall in the command is important. For this reason, a pure pattern matcher will fail. The first select is the verb or the command; the second is the column to be retrieved, while the third one is the table accessed. The above example can be extended to complex joins or long stored procedures or block-level file activity – the key is to understand the semantics or the context of the actual activity.
Abstract Application Model for Breadth:
When a Digital Asset Management system is architected it should be able to translate the output of the parsers into a common abstract application model. For example, application activity within a database and application activity within a file server has to be translated into a common data activity model. This model should be abstract enough so it can extend as new applications added to the Digital Asset Management portfolio. The simplest examples of abstraction are: commands that look like “select” in databases are analogous to “read” in the file-server. A table and column within a database need to be rationalized against a “file” within a fileserver. Similarly, when data is retrieved, it could be retrieved in rows in a database vs. blocks of bytes in a file server. The same abstraction concept is also critical when you consider different database applications (Oracle vs. SQL Server vs. Sybase vs. DB2 for example) or different versions within the same application family (say Oracle 9i vs. 10g vs. 11g vs 12c). As logging and access formats change with versions or applications, an abstract application model is what rationalizes the activity and allows extensibility.
When you want to make a strong Oracle DBA career then you should be aware of database services and other database technology. Without having knowledge of Oracle internals, Oracle performance tuning, and skill of Oracle database troubleshooting you can’t be an Oracle DBA expert. This expert DBA Team club blog always provides you latest technology news and database news to keep yourself up to date. You should need to be aware of Cloud database technology like DBaaS. All Oracle DBA tips are available in a single unique resource at our orageek. Meanwhile, we are also providing some sql tutorials for Oracle DBA. This is the part of Dbametrix Group and you would enjoy more advanced topics from our partner resource.
