9 - Access control

9.1 Business requirements of access control

Objective : To limit access to information and information processing facilities

9.1.1 Access control policy

The access to the Service is restricted to identified and authorized users. Some functionalities are restricted to specific groups of users, e.g. Administrators of the Service, defined by the Client.

The access to the data of the Service and its underlying infrastructure by 365Talents' employees and contractors is limited to specifically authorized people.

The access to the data of the Service by 365Talents' providers is not permitted except for the provider in charge of the transactional e-mails and, under contractually defined and limited circumstances, to the hosting provider.

9.1.2 Access to networks and network services

Direct access to the Service production network is not allowed to the Clients.

The access to the data exchange services used by the Clients to send data is authorized via the Internet network and only through :

• sFTP over SSH-2 after authentication through a pair of public/private keys
• API after authentication

Direct access to the Service production network is not possible, authorized employees and contractors of 365Talents must use a secure VPN connection.

9.2 User access management

Objective : To ensure authorized user access and to prevent unauthorized access to systems and services.

9.2.1 User registration and de-registration

Registration and de-registration of the users of the Service is under each Client responsibility.

Registration and de-registration are realized through the regular provision by the Client of a list of users via data exchange services (See 13.2.1, 14.12&14.1.3). Registration and de-registration (or deactivation) can also be realized by the Administrators of the Service appointed by the Client through the Service administration interface. Accounts are nominative and unique ; generic accounts are not permitted.

Every employee and contractor using 365Talents information system ("Users") are provided with a unique and nominative IDs : their e-mail address.

On a need-to-know basis, Users can be provided with a unique and nominative ID to access the platform environments and assets (production, pre-production & development servers and databases, network components, security components, ...), different of their e-mail address. Creation and usage of generic ID is limited to the strict minimum needed. 365Talents policy is to reduce their number and usage whenever possible.

IDs of Users that have left 365Talents are disabled immediately and then removed in a timely manner.

9.2.2 User access provisioning

Service user access management

Access provisioning of the users of the Service is under each Client responsibility. Access provisioning is realized through the regular provision by the Client of a list of users with associated granted accesses via data exchange services (See 13.2.1, 14.12&14.1.3). Access provisioning can also be realized by the Administrators of the Service appointed by the Client through the Service administration interface.

Access management for 365Talents internal populations

Access provisioning of the employees and contractors of 365Talents is based on a formalized procedure, standard access matrix based on job functions and exceptions formalized.

Profiles of internal populations likely to access the service or the infrastructures set up to provide it:

New employees and contractors of 365Talents are not granted access to any 365Talents production systems until after they have completed all HR on-boarding tasks, which may include but is not limited to sign the employment agreement, sign the intellectual property agreement, and acknowledgement of 365Talents's information security policy. 

Other accounts and accesses may be created before user's arrival but initial secret authentication information is communicated to the user only after completion of all HR on-boarding tasks. 

Access is restricted to only what is necessary to perform job duties. 

No access is granted earlier than official employee start date. Access requests and rights modifications are documented in an access request record. 

Standard accesses for the role and job functions, as defined in the Access Matrix, are considered as approved by default and are granted during the onboarding process. No other permissions is granted without approval from the system or data owner or management.

9.2.3 Management of privileged access rights

Management of privileged access rights of the Service is under each Client responsibility.

Management of privileged access rights can be realized by the Administrators of the Service appointed by the Client through the Service administration interface.

The Service does not allow the use of generic administration accounts.

Access to the platform environments and assets (production, pre-production & development environments of the Service, servers, databases, network components, security components, ...) is restricted to the authorized Users on a need-to-know basis. Their IDs are nominative. Their access rights are strictly personal, based on the least-privilege principle, regularly reviewed and adjusted if needed, and immediately removed when Users leave 365Talents.

These accounts are automatically banned after 6 failed login attempts within 10 minutes.

Creation and usage of generic ID with privileged access rights is limited to the strict minimum needed. Their usage is restricted to authorized users. 365Talents policy is to reduce their number and usage whenever possible.

9.2.4 Management of secret authentication information of users

If the authentication to the Service relies on a SSO solution of the Client, the management of secret authentication information of users is under each Client responsibility.

If the authentication to the Service relies on the Service itself, the management of secret authentication information of users is controlled as follow :

• Users responsibilities to keep their password confidential is under each Client responsibility.
• If login/password are used, a temporary password is provided initially by the platform and must be changed on first use. This password is provided to each user in the form of a magic link sent to its e-mail address with a time-limited validity.
• If Magic links are used, the authentication secret is a token embedded in the magic link.
• Users can requests a reset of their password through a dedicated form.

9.2.5 Review of user access rights

Review of access rights of the Users of the Service is under each Client responsibility.The Clients can export of the list of the users directly on the platform (given the user performing the export has the appropriate access rights). This export contain for each user its login, its profil and the timestamp of the last connection.

365Talents performs an annual access rights review, in particular the access rights giving access to the data of the Clients.

The scope of the review includes :

• A review of the standard accesses matrix, which associates business roles with access to various resources.
• At a minimum, all access to resources directly or indirectly linked to the Service, such as our Azure environment (infrastructure SSO), our Github environment and our Google environment (desktop SSO). Non-compliances are either remediated (rights removed or adjusted), or the standard access matrix is updated if the rights are deemed justified and should be maintained and standardized.
• Access to other resources, which are exclusively internal to 365Talents and do not contain customer data, may or may not be included in the review, depending on the risks and changes in the corporate context.

9.2.6 Removal or adjustment of access rights

Removal or adjustment of access rights of the Users of the Service is under each Client responsibility.

Removal or adjustment of access rights is realized through the regular provision by the Client of a list of users with associated granted accesses via data exchange services. Removal or adjustment of access rights can also be realized by the Administrators of the Service appointed by the Client through the Service administration interface.

9.3 User responsibilities

Objective : To make users accountable for safeguarding their authentication information

9.3.1 Use of secret authentication information

The use of secret authentication information by the Users of the Service is under each Client responsibility.

9.4 System and application access control

Objective : To prevent unauthorized access to systems and applications.

9.4.1 Informations access restriction

The access to the information and functionalities of the Service is restricted to the Users authenticated.

The access to information and functionalities of the Service can fine-tuned by the access rights of each User :

• Default access rights : The User can only read and modify of its own data.
• Granular access rights : The User can read, modify and delete data on pre-defined subset of data or modify a pre-defined subset of functionalities of the Service.
• Extended access rights (Administrator of the Service) : The User can read, modify and delete any data or modify any of functionalities of the Service.

It is possible to create as much profile as needed. All the informations related to access rights profiles are stored in a table of the database. Each user is associated to a profile in another table of the database.\
The logical access controls inherited from the profile are systematically applied by the back-end software to avoid unauthorized read or write accesses.

9.4.2 Secure log-on procedures

Log-on to the Service is secured as follow :

• In case of usage of a Client's Single Sign-On (SSO) : secure log-on policy of the Client is applied. The authentication can rely on any external referential taking in charge SAMLv2 or OpenID protocols.
• For other case, secure log-on is managed by 365Talents and the Service :
• validate the log-on information only on completion of all input data. If an error condition arises, the system does not indicate which part of the data is correct or incorrect;
• is protected against brute force log-on attempts (automatic ban after 10 failed log-on attempts within 10 minutes);
• log unsuccessful and successful attempts;
• doesn't display the password being entered;
• doesn't transmit passwords in clear text over a network;
• terminate inactive session after a defined period of inactivity (8hours by default, customizable);
• terminate session after log-out.
• Once the user is authenticated, the authentication information are stored on the user's workstation in a cryptographically signed token ("JWT Token") transferred through HTTPs (See 10.1, 13.2.1 and 14.2.2&14.2.3 for JWT & HTTPs security measures).
• At the moment the Service doesn't natively support multi-factor authentication.

The authentication on data exchange services is secure as follow :

• sFTP : Verification of a pair of public/private keys.
• API :
• Public APIs provided by the Service:
  • Access to the Service's public APIs is authenticated using JWT authentication (challenge login/password). JWT tokens are signed by a server key controlled by 365Talents (see 6.1 and 6.2). The HTTP authorization scheme is Bearer Token. All API requests must be authenticated via the Authorization header. All requests with a signed JWT for a defined user will give access to APIs limited to that user's rights and authorizations.
  • Security Scheme Type : HTTP
  • HTTP Authorization Scheme : bearer
  • Bearer format : "JWT
• Private Service APIs :
  • Same approach as for public APIs, but after user authentication (via SSO or login/password, depending on the scheme chosen by the customer).
• APIs for interfacing the Service with customer applications:
  • Customer applications wishing to interface with the Service via APIs to feed data into the service can be authenticated by any method, depending on the capabilities of the customer application: Authentication Header, pre-shared API keys, OAuth (Client ID/Secret), …

Log-on to infrastructure components by technical team of 365Talents :

• SSH Log-on with password not allowed, key pair exchange only.
• Accounts are automatically banned after 6 failed login attempts within 10 minutes.

Log-on to the Databases by the application :

• The applicative accounts enabling the application to connect to the DataBases are different from the default account and specific to each Client. Moreover the passwords used to access the databases are randomly generated.

9.4.3 Password management system

In case of usage of a Client's Single Sign-On (SSO) authentication method to connect to the Service, the password management is under each Client responsibility.

In case the "login/password" authentication method is implemented, password management is implemented by 365Talents. The Service can enforce a password policy compliant with the Client's password policy with following parameters:

• Password minimum length
• Password complexity :
• minimum number of lower case
• minimum number of upper case
• minimum number of number
• minimum number of special characters
• Password should be different of :
• First name
• Last name
• User ID
• Previous passwords (number customizable)
• Password expiration delay

The password are then encrypted by a one-way algorithm before being stored in a database (see 10.1 Cryptographic controls).

Every members of the technical team of 365Talents is required to use strong passwords. Whenever possible the following password policy is applied to privileged accesses :

• at least 16 characters
• at least 1 Upper case
• at least 1 lower case
• at least 1 number
• at least 1 special character

9.4.4 Use of privileged utility programs

The usage of the Service doesn't require :

• installation of any plug-in,
• installation of any other kind of program
• any additional content,
• any inbound connection
• to store any kind of treatment data
• any kind of privileges

on the workstations of the users or administrators of the Service. 
 

9.4.5 Access control to program source code

The source code of the Service is stored in a decentralized versioning management system (git).

The access to this system is strictly limited on a need-to-know basis.

Every modification of the source code is logged. Information logged contains :

• Unique ID of the change
• Unique ID of the User that performed the action
• Timestamp
• An explanatory message of the change