Sage CRM is a product that has an expectation that its users are going to want to access the system from a wide variety of locations, both inside and outside the corporate network and that they will be accessing it using a range of different devices.
That means that when planning an implementation some thought will need to go into the questions
- Who can access the system?
- Where can they access the system?
- What can they see and do within the system?
I have assumed that you have read the section in the System Administration guide that discusses the installation of a secure system. The following link will take you to the documentation for Sage CRM 2018 R1: http://help.sagecrm.com/on_premise/en/2018R1/administration/Content/InstallUpgrade/SV_ServerSecurity.htm
Consider the image below.
This shows a simple way of thinking about the implementation of Sage CRM.
Here users within the corporate network can access Sage CRM through their browsers. The web server and the actual Sage CRM application are physically on the same machine. See the article "System Architecture" for more background information.
At this point we can consider application security, network security and database security.
Users in Sage CRM can be set up so that they experience Sage CRM in very different ways. Individual users will authenticate using their username and passwords but because they belong to different teams, or are assigned different security profiles they will find they have very different rights. These rights control access to functional areas of the system such as marketing or the ability to create and edit reports or to send mass emails or export data. These settings control a users ability to insert, edit or update data. A user can be denied access to any main entity within the system, for example a user not allowed to see any cases would have see an user Interface that completely hid all reference to the Case entity. If a user can not update a record then the change button will not appear. This level of control goes down to individual fields that a user may or may not access.
These are all examples of in-application security. This type of security is about how the user is controlled while they are inside Sage CRM.
But what about the usernames and passwords themselves?
In Sage CRM password policies can be set to ensure strong passwords of a minimum length, that are complex and that expire regularly and need to be changed and where the user is only allowed a small number of failed attempts at logins before their account is locked. User security can also be integrated with NT Challenge and Response, in Sage CRM this is known as IIS Autologin. Users can be set up so that if they have logged into their windows machine Sage CRM can takes advantage of Integrated Windows Authentication to allow those users immediate access to CRM provided their windows logon is the same as the their Sage CRM userid.
Access to the application server is one thing but we also need to consider access to the database. I have discussed in a previous article how Sage CRM has a hybrid architecture.
The database has to be accessed through both ADO and JDBC. The connections are shared connections between the application and the database. In the case of SQL Server then you will need to use SQL Authentication to ensure that both the eware.dll and the Tomcat based side of the system can access the database in the same way. You can see this during the installation or upgrade process.
You shouldn't use the database 'sa' user in a live system. The database logon used by Sage CRM needs to have the rights to add, delete, and change data in every table within the Sage CRM database.
Sage CRM's interface can be extended using either the classic ASP API or using the .NET API. New screens created for Sage CRM using the APIs inherit the security policies that control users in the main interface. If a user can not do something in the main interface they will not be able to do it within the custom screens. The sessions for the customised area all use the same database access as the rest of the interface.
External applications that access Sage CRM follow the same security rules for the users sessions that they use. If an user not insert a company record in the main interface then that userid when used for SOAP web services will neither be able to insert into the company table. In addition the ability for individual userids to be used for external logons or SOAP web services transactions can be be limited. If an user logon is not explicitly enabled for web services then it is impossible to access CRM using that account.
Sage CRM can be set up to use HTTP/SSL to ensure still greater security when passing data and user credentials. This is a very important consideration when accessing CRM using the SOAP and SData as these pass data in plain text and so should be encrypted.
The documentation discusses this in more detail.
It is likely that an implementation will require you to think about how users will access the system from beyond the corporate network. In these circumstances Sage CRM's web server is likely to be placed within the organisations Demilitarized Zone (DMZ). This can be either a implemented as a physical or logical subnetwork that exposes the web server to the Internet.
In addition you may wish to further control access through the use of a VPN.
If your users need to access Sage CRM either through the mobile optimised screens (Tablet, iPhone or Android) or through the mobile apps then these users can be set up as mobile firewall users so they can access the VPN and transmit and receive data securely.
Access to Sage CRM through mobile devices can also be controlled through the administration screens. This means users can be selectively given permission to access Sage CRM through those devices.
Other options for Sage CRM's installation include the use of Terminal Services and Citrix which are discussed in the system documentation.
This has only been a brief overview of system security within Sage CRM and other articles expand on the subjects mentioned here in more detail. There are separate articles on creating security profiles, the use of APIs and the creation of mobile screens in addition to the installation of Sage CRM and the system requirements.