Difference between revisions of "Security and Best Practice"
(→Project Access) |
|||
| (15 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
[[File:helpheader_small.png|right]] | [[File:helpheader_small.png|right]] | ||
| − | The system has a host of security features as standard with a wide range of additional options. | + | 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 your system even more secure. |
=Security related to users logging in= | =Security related to users logging in= | ||
| Line 9: | Line 9: | ||
'''This feature is planned to be replaced with the use of email addresses for users.''' | '''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 | + | At present you can force user names to have a minimum length, to include upper-case characters and numbers. |
| − | [[File: | + | [[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 | + | To use this feature, go to: |
| + | |||
| + | 1) Cog | ||
| + | |||
| + | 2) Logging In / System Access | ||
==Password rules== | ==Password rules== | ||
| Line 38: | Line 42: | ||
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. | 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: | + | [[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]]. | 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== | ||
| − | + | 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#2_Factor_Authentication| Logging In / System Access]]. If you are enabling this for the first time and you have a lot of users, you may want to consider enabling this for one user group at a time to help with the transition. | |
| + | |||
| + | To configure SMS messages, see [[TextAnywhere]]. | ||
==Restricting users by location== | ==Restricting users by location== | ||
| Line 54: | Line 60: | ||
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. | 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]]== | ==[[Group Access]]== | ||
| Line 61: | Line 70: | ||
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. | 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 sets. | ||
| + | * 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]] | [[File:helpheader_small.png|right]] | ||
Latest revision as of 13:56, 13 September 2024
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 your system even more secure.
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 minimum length, to include upper-case characters and numbers.
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.
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
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 Logging In / System Access. If you are enabling this for the first time and you have a lot of users, you may want to consider enabling this for one user group at a time to help with the transition.
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:
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 to specify access per user, or see 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 setup to link the field sets.
- See Users or Project Set Up to specify which projects a user has access to.
Restricting which Service Users a user can see
Via the 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 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.
