Difference between revisions of "EGI-CSIRT:TDG/best pract"
Line 13: | Line 13: | ||
Of course, again, this mechanism is efficient only if the private key is protected by a good passphrase! | Of course, again, this mechanism is efficient only if the private key is protected by a good passphrase! | ||
== Business Continuity == | |||
A critical area of the system documentation is the business continuity plan. | |||
This document is part of the system risk analysis, in the event of a major disaster. | |||
The aim of this document is to provide detailed procedures that need to be followed in order to maintain a service when a major disaster occurs. For instance, hot spare backup machines, backup tapes or off-site mirror can help restoring a service prompty when required. | |||
Ideally, a business continuity plans contains enough details to be followed and fully executed by non-expert staff. | |||
It is far from easy to define a reasonable business continuity plan. Every aspect of the plan needs to be carefully defined in order to ensure that it can be used at anytime. | |||
Therefore it needs to be defined and agreed in advanced in order to be fully effective. |
Revision as of 15:39, 15 March 2012
EGI-CSIRT Public wiki EGI-CSIRT Private wiki
EGI-CSIRT Contacts | Back to TDG Main
Best Practices
Protecting Administrative Credentials
Credentials to access systems or Grid services should be well protected to prevent attackers from gaining access to the system or one of its services.
For instance, for Grid services, the certificate private key (generally stored in userkey.pem or *.p12 files) is the secret part of the information representing the identity of its owner. This information is secret and must remain readable only by its owner. If the private key becomes known to an attacker, he/she will have the ability to impersonate the owner of the certificate on the Grid. While protecting private keys is under the responsibility of their owners, when allowed, site administrators are encouraged to periodically search for publicly readable private keys on their hosts. Unprotected and publicly readable private keys should be sent to the relevant CA for revocation.
Also, SSH bruteforce attacks are very common and it is recommended to use SSH keys authentication instead of password authentication to authenticate against remote SSH servers. Indeed, once the SSH public key is stored on the remote server, it is possible to authenticate against it by using the relevant SSH private key, which is protected by a passphrase.
Of course, again, this mechanism is efficient only if the private key is protected by a good passphrase!
Business Continuity
A critical area of the system documentation is the business continuity plan. This document is part of the system risk analysis, in the event of a major disaster.
The aim of this document is to provide detailed procedures that need to be followed in order to maintain a service when a major disaster occurs. For instance, hot spare backup machines, backup tapes or off-site mirror can help restoring a service prompty when required. Ideally, a business continuity plans contains enough details to be followed and fully executed by non-expert staff.
It is far from easy to define a reasonable business continuity plan. Every aspect of the plan needs to be carefully defined in order to ensure that it can be used at anytime. Therefore it needs to be defined and agreed in advanced in order to be fully effective.