View source for Security and Best Practice

[[File:helpheader_small.png|right]]

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.

=Security related to users logging in=
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.

[[File:user_name_rules.JPG|900px|alt="a screenshot of the user name rules. This allows you to define the rules around the character lengths of the user names."]]

To use this feature, go to:

1) Cog

2) Logging In / System Access

==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#Password Rules|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.

[[File:failed_logins.JPG|900px|alt="a screenshot of the failed log ins settings, where you can specify a time period between users logging back in after a failed login."]]

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#Security Rules - Failed logins|Operational Rules]].

==2 Factor Authentication==
2 Factor Authentication (2FA or MFA) adds an important extra layer of security by emailing/texting the user a unique code each time they log in.

To activate the 2FA, see [[Operational_Rules#Security_Rules_-_2_Factor_Authentication| Operational Rules]].

To configure SMS messages, see [[TextAnywhere]].

==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:

* [[Restricted IP Addresses|Add the IP addresses to the system.]]
* [[Group Access|Restrict the Group Access to the 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.

=Security for what a user can access=
In this section you will see the features that tailor what areas of the system the user can access, or see.

==[[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#Project Access|Users]] to specify access per user, or see [[Project Set Up#User Access|Project Set Up]] for bulk editing users.

==Which Fields are visible to your users==
Filed sets can be created and attached to projects, which will specify which fields a user has access to.  When a user logs into the system their user record is checked to see which projects they have access to, the project will then specify which fields are required.  When a user views a record the system will display all the fields required by the projects for the user.

* See [[Field Sets]] to specify the groups of fields
* See [[Project Set Up#Field Sets tab|project setup]] to link the field sests.
* See [[Users#Project Access|Users]] or [[Project Set Up#User Access|Project Set Up]] to specify which projects a user has access to.

==Restricting which Service Users a user can see==
Via the [[Users#Navigation|User record]] you can specify that a user can only see their own clients.  'See my own clients' can be tailored to specify which client scenarios a user should see.

==Branch Access==
An addition option for the system is the [[Modules|Branch Feature]], which allows the system to be separated into secure branches.  Users can be restricted to individual branches so that they can not see service users and work done in other branches.

----
[[File:helpheader_small.png|right]]