The repository is the primary type of audit data store in InTrust. The other type is the audit database. Repositories are intended for long-term archiving of data in a compressed format. You can do the following with an InTrust repository:
File-based repositories can store large amounts of data (because it is compressed), and they have a hierarchical structure, which ensures fast access and easy data selection and retrieval.
Repositories of this type differ from arbitrary file system hierarchies in that they contain files with very long paths and need specialized tools for handling. This means that some generic file and folder operations may not work with file-based repositories. For example, it is not recommended that you copy a repository to another location as you would a regular folder or share. For information about copying and backing up repositories, see the Cloning Repositories topic in this document.
Centera is a powerful networked storage solution that integrates hardware and software components. Audit data is one of the types of data that Centera is designed for. Event records must remain unchanged once they are created, they need to be retained as long as compliance regulations specify, and they should always be readily available.
To successfully set up Centera-based repositories, an InTrust administrator should at least be familiar with the basic concepts described below, which have a direct bearing on interoperation between InTrust and Centera. For additional information, refer to the Centera documentation.
Centera offers the following advantages over file-based repositories:
A cluster is the largest physical unit of a Centera storage. Clusters are made up of cubes. Cubes contain between 4 and 32 nodes, which are the smallest physical elements.
Failover facilities are cluster-wide, meaning that you ensure failover for the entire cluster rather than specific nodes.
A node is a physical device that can be represented by a network identity and can act as an interface between the network environment outside the Centera cluster and the data stored in the cluster.
Whether the node can provide this interface depends on the role it is assigned. The following roles are available for Centera nodes:
Nodes with the access role are gateways to the data stored in Centera. These nodes have IP addresses on the network and are responsible for authentication. If you successfully connect to one such node, you have access to the entire cluster. However, to connect faster, you can specify several available nodes with the access role.
Applications such as InTrust use these nodes to access the storage facilities. The properties of a Centera-based InTrust repository include the IP address of the Centera node with the access role that provides data access.
Centera is designed for access by applications, not by security principals. For this reason, security is configured on a per-application basis and does not involve any accounts in the environment.
Centera authorization is also built around this model. Centera provides application profiles that determine which data is made available to specific applications.
The Centera cluster must have an application profile for InTrust before any jobs can use the Centera-based repository. The properties of a Centera-based InTrust repository include settings for all supported authentication methods.
For more information, see the Creating and Editing Repositories topic.
Centera associates retention periods with the data it stores, based on the properties of the data. A retention period is the period after which the data can be deleted by an application that works with it.
Retention models differ depending on the Centera edition: Basic, Compliance Edition Plus, and Governance Edition. For more information, refer to the Centera documentation.
The properties of a Centera-based InTrust repository include retention period settings. For more information, see theCreating and Editing Repositories topic.
Working with Centera-based repositories is essentially the same as working with file-based repositories. You can select the type—file-based or Centera-based—when you create a repository. Further settings depend on the repository type you select.
Although there are differences in repository properties, the auditing workflow is uniform for both types. Whichever type of repository you create, you can use it in any job that involves repositories.
You cannot convert one repository type to another. However, you can use InTrust consolidation jobs to relocate data.
From the user perspective, the difference is that Centera-based repositories cannot be viewed in InTrust Repository Viewer. Instead, use the Legacy Repository Viewer MMC snap-in shipped with InTrust.
A Centera-based repository is a split structure that has two parts:
The service folder does not contain actual audit data, but redirects InTrust to the Centera node and helps perform read and write operations. This service data cannot be located in the Centera node, because this contradicts Centera's data immutability requirement.
Therefore, connecting to a Centera-based repository is different from connecting to a file system-based repository. To access Centera, InTrust must have access to both of the locations.
Although a Centera-based repository is made up of two parts, it should be considered a single unit. The service folder must always reference data in the same Centera cluster; otherwise, the data will become unavailable.
For example, the properties of a Centera-based repository must always specify access nodes that belong to the same cluster. Supplying the IP address of a node in a different cluster will not prevent gathering, but will result in data unavailability.
In addition, if the IP addresses of your Centera nodes with the access role are changed, edit the properties of your Centera-based repositories accordingly.
Connections to production repositories normally occur through an InTrust server, unlike connections to idle repositories. The distinction between these two kinds of repository is as follows:
For successful connections to production repositories, make sure all InTrust servers in the organization have the agent communication port (900 by default) and InTrust Server management port (8340 by default) open for inbound traffic.
Make sure that the file server where you create a new repository share has fast and reliable connections to InTrust Server.
To create a file-based repository in InTrust Deployment Manager
To create a file-based repository in InTrust Manager
To create a Centera-based repository (only in InTrust Manager)
To edit an existing repository
The same configuration options described in the procedures above
The New Repository Wizard can automatically generate Centera connection strings using the values you specify.
On the Connection Settings step, specify the names or IP addresses of Centera nodes with the access role. The default port for connection is 3218; specify a different port number if necessary.
On the Security Settings step, configure the Centera authentication method InTrust must use by choosing one of the following:
After you have created a Centera-based repository, these settings are available in the repository’s properties dialog box on the Centera tab.
Every unit of data in Centera has a retention policy associated with it. The retention policy determines how long the data is kept before it expires and can be cleared.
Centera retention policy settings for audit data gathered with InTrust are not specified during repository creation. To access retention policy settings, open the properties of a Centera-based repository, select the Centera tab, and click Retention Policy.
You have three options for audit data retention, as follows:
Retention policy settings have precedence over InTrust repository cleanup job settings. If you run a cleanup job on a Centera-based repository where the retention period has not yet expired for the specified data, then the data is not deleted, and the repository cleanup session will contain errors. Centera permits cleanup procedures only after the retention period has expired.
InTrust repository indexing is a big topic, described separately in Repository Indexing for Advanced Search Capabilities.
© ALL RIGHTS RESERVED. 이용 약관 개인정보 보호정책 Cookie Preference Center
