Quantcast
Channel: Système informatique, sécurité et Web
Viewing all articles
Browse latest Browse all 187

Filer mgmt Best practice secu

$
0
0

Filer management is a sensitive activity due to the following reasons

  • File servers datas are critical for the business
  • File servers are used by the applications

 

One critical point is also related to the security management (in order to ensures that datas are well protected avoiding rogues access). The security is also part of the disponibility of the service.

 

The aim of this document is to reaffirm the best practices in order to standardize the approach for filer across all CA-CIB offices.

 

Share Naming

The share name should be keep as short as possible without spaces on it and match with the name of the folder on the disk. (For instance D:\SHARE_1 shared as SHARE_1). Of course in case of hidden folder you will need to complete share name with “$”.

 

One folder = one share, do not share again (even under the share). For instance D:\SHARE_1\TEST folder cannot be shared twice (1 time as SHARE_1 at the D:\SHARE_1 level and 1 time as TEST at the D:\SHARE_1 \TEST level

 

For applicative shares the name should allow the identification easyly with :

  1. The name of the application (by using the CASEWISE code)
  2. The environment (PRD, INT,DEV…) è Datas should be segregated across shares for instance one share for Production and another one for preproduction.
  3. In order to enhance the lisibility separate fields with _ for instance CCC_PRD for CCC application share with production datas.

Applicative shares must contain only applicative datas (no mix with corp / group datas or end users datas)

 

Share Usage

The usage of a share must be clearly defined with the client. Usage, purpose… In case of shares for application it’s recommended to ensure:

  • The structure of data
    • Folder tree depth
    • Number of files (hundreds, thousands, millions)
    • Number of simultaneous connections
  • Change/ update frequency

 

Security and ACL management

The use of built-in groups is prohibited for granting access to users

  • No Everyone
  • No Authenticated Users
  • No Anonymous
  • No Domain Users (or default Server\Users group)

 

If you need to grant access to a large set of users by using these groups please refer to your local compliance officer.

 

Active Directory Groups must be created for each share (no reuse of groups across multiple shares) and the share name must be visible in the group name. Never use server local groups to grant access to a share (always domain local or universal groups)

 

The group name must reflect the rights on the share (the group name should ends with _R for Read , _RW for Read/Write, _L for list only).

 

For instance DL_SHARE1_RW for access to Share_1 with Read-Write access.

Note that giving access with Full Control is not allowed to end users. Full control is only permitted to Administrators.

 

When sharing a folder you can change the permission up to 2 levels by using specific groups.

 

 

All access must be secured at the NTFS Level only, Permissions at the share Level must be Everyone Full control only.

 

 

Do not configure permissions at this level; Only NTFS rights must be used.

 

Never grant access directly to a user (Except for home-directories).

 

 

Share management recommendations

When a share is created it’s important to identify the stakeholders that are reliable in the time.

  • For an application identify the owner
  • For a data share the business line associated

 

This will help to identify the validator for granting access and the contact in case of operation over the share.

In case of reorganization in a department the best practice is to try to recreate a new folder structure with appropriate rights:

  • Preventing unwanted access
  • Ensures that only validated users can access to the data
  • Fit with the business needs

 

Even if this could be heavy it’s the best way to avoid historical problems if an audit occurs.

 

When providing a share resource the best practice is to challenge the requester regarding the size.

Quotas must be configured for all shares, according to business needs, if no quota is configured takes the actual size and set a quota at 20% more (for instance if a no quota share have 100GB used set a quota at 120GB).

 

When possible, try to configure an alert by E-Mail to the owner if the quota as reach 85% in order to be proactive and avoid a blocking saturation. The monitoring of disks saturation should be realized on a regular basis (follow of disks usages and quotas occupation). Even if it’s possible to overprovision quotas (for instance allowing 4 shares with 50GB quotas on a 100GB disks) it should be done with caution.

 

Filers infrastructure disponibility and security

The file server infrastructure that hosts the shared folders in production, whatever the solution, must meet the following requirements:

 

  • DR compliant with a RTO at 4hrs MAX and a RPO at 30mins MAX.
  • Security Patch management must be realized at least on a Quarter basis.

 

Backups are mandatory and the strategy must be shared with the client in order to avoid misunderstood (especially regarding the recovery time in case of issue). Try to limit the size of disks / volumes in order to prevent a too large downtime in case of scandisk or partition corruption (less than 2 TB per drives for Windows 2008R2 and up to 4TB per drives with Windows 2012R2 thanks to chkdsk online improvments).

 

Regular IRVS scans must be realized by SIT team in order to identify potentials vulnerability.

 

Whatever the solution retained to host the files servers it must provide an antivirus solution in order to protect the resources against virus.

 

As part of the best practices it’s important to segregate administration in order to ensure that peoples who are performing administration tasks only have the proper level of rights over the system (no need to be full administrator to create a share, change a quota or modifying permissions). Always keep in mind the less privilege principle.

 

All request to access to a file share must be traced, at least through a ticketing tool (such as service center or equivalent solution) or by using GRANT. For each request a validation of the owner of the data (BLAO) or the requester manager is necessary.

A project (DIAM) is currently under deployment to automate GRANT workflow in order to have a fully automated process (up to the user account addition / removal in the resource group) with consistency checks between the declared access in GRANT and the group membership (with dynamic correction).

 

 

The solution providing file server’s services must provide audits in order to retrieve who have make changes over a folder. CA-CIB has standardized VARONIS Datadvantage for this purpose. This solution allow administrator to track users activity for compliance needs but also help administrators to identify old data’s (never accessed since 18 month for instance) for archiving purposes.

 

A review of all shares (at least 1 review by year) to prevent unwanted access is mandatory. The aim of this review is to ensure that no open ACL are configured (Everyone, Authenticated users, Domain users…). SSS team can help local team by providing some home-made tools for that.


Viewing all articles
Browse latest Browse all 187

Trending Articles