Difference between revisions of "Security and Best Practice"
(→Project Access) |
(→Project Access) |
||
| Line 59: | Line 59: | ||
==Project Access== | ==Project Access== | ||
| − | On each user you can specify which projects they have access to. You specify that a user can create a referral/case for a project, access the details of a project or simply see which projects a service user is accessing. For details on project access see [[Users]] to specify access per user, or see [[Project Set Up#User Access]] for bulk editing users. | + | On each user you can specify which projects they have access to. You specify that a user can create a referral/case for a project, access the details of a project or simply see which projects a service user is accessing. For details on project access see [[Users#Project Access|Users]] to specify access per user, or see [[Project Set Up#User Access|Project Set Up]] for bulk editing users. |
Revision as of 10:40, 15 March 2019
The system has a host of security features as standard with a wide range of additional options. On this page you will find details of features and guides to make you system even more secure.
Contents
In this section you will find features related to the general access of the system.
User name rules
This feature is planned to be replaced with the use of email addresses for users.
At present you can force user names to have a minumum length, to include upper-case characters and numbers.
To use this feature please see Operational Rules.
Password rules
The system can force users to use secure complex passwords. This will reduce chance of passwords being guessed by unauthorised people. Password rules are also used to protect against 'Brute Force Attacks' (when a combination of characters for the user name and password are entered until access is granted).
The following rules are available:
- Minimum Length of User Passwords - Recommended to be at least 8 digits in length.
- Minimum Number of Upper Case Characters In Password - Recommended to include at least one upper-case character.
- Minimum Number of Numeric Characters In Password - Recommended to include at least one numeric character.
- Minimum Number of Non Alpha-numeric Characters (_:!&()?-@,.+) in Password - Recommended to include at least one special character.
- Maximum Number of Identical Consecutive Characters In Password - Recommended to be set to two.
- Allow User's System Username In Password - Recommended to not allow user names in the password.
- Allow User's Real Name In Password - Recommended not to allow a persons real name to be used in a password.
- Allow Organisation Name In Password - Recommended not to allow the organisations name to be used in a password.
- Allow Browser to Save Username and Password - This tells the browser that the password is not to be saved (stored) on the local machine (this is ignored by some browsers).
- Do not allow the reuse of previous Passwords - Recommended that at least 10 different passwords variations should be used before re-using a previous password.
- Number of Days Before User Password Change Required - This is recommended to be set to a period between 30 and 90 days.
Password security is essential to protect the data in the system. The above are general reconsiderations, however making passwords too secure can also threaten security. If passwords are made to be too complicated for users to remember, there is a high chance that the user may be tempted to write them down (or even attach them to their monitor or underside of their keyboard).
To set the password rules please see Operational Rules.
Failed logins
A person can be restricted access the system if they enter an incorrect user name or password, this helps prevent or delay 'Brute for Force' attempts.
You can specify a time period before the user can log back in and a set number of attempts. This is recommended to be set from 10 to 30 minutes after 3 failed attempts. If you specify that the administrator must unlock the account then the time is ignored. The administrator would need to go to the Uesers record to unlock the account. To set these rules please see Operational Rules.
2 Factor Authentication
You are able to activate 2 Factor Authentication using the TextAnywhere facility. When logging in the user will be sent an authentication code that needs to be entered on the screen. To set up the text service please see TextAnywhere and to activate the two factor authentication please visit Operational Rules.
Further information being added to this page.
Restricting users by location
Users can be restricted to only log in from certain locations, this facility uses the IP Address of the locations router (an address supplied device that connects to the internet). If you wish to use IP restriction you will need a static IP Address supplied by your internet service provider. There are two steps required to activate restricted IP addresses:
To find the IP address for a location that you are at do a search (supported by most major search engines, Google, MSN, Duck Duck Go etc) on the internet for 'what is my ip', you will be displayed the IP address for your current location at that time.
Group Access
One key area of security to look at is the Group Access accounts, these groups are used to specify what users can do and access the system. Each role can be defined grating access to records, reporting and administration of the system. Administrators can define the security that is required for the organisation.
Project Access
On each user you can specify which projects they have access to. You specify that a user can create a referral/case for a project, access the details of a project or simply see which projects a service user is accessing. For details on project access see Users to specify access per user, or see Project Set Up for bulk editing users.
Project Access Group Access See my own client Field sets
