- 2 minutes to read
Best Practices for Use
- 2 minutes to read
In this chapter you will find a list of best practices for the safe use of the WebService A2A module. If you have any questions, please contact our support team.
Set only one credential per WebService A2A authorization.
In this way, this practice will reduce the risk surface since the authorization will be tied to only one credential; thus, the tracking of activities is centralized. In case of vulnerability, the response will be faster by disabling one credential instead of several.
Define that WebService A2A authorization has the origin IP restriction set only for the Servers (and their redundancies) that manage the applications that need access to the credentials of senhasegura .
Be aware that the principle of least privilege should also be applied to machines, defining a policy that grants access only to servers that performing their tasks need to use the credentials managed by senhasegura .
Give preference to using the Oauth 2.0 signature (more secure) over using Oauth 1.0.
Always opt for the most up-to-date standards that correspond to more robust security levels and are compatible with your asset technology.
Enable the Enable encryption of sensitive information functionality for queries through the senhasegura API, and segment that the credential query module and the sensitive information decryption module, be performed by different developers, so that none of them has access to the complete information (Credential query and decryption);
Implement the query for the credentials needed by the application, so that they are brought in during application execution, and no need to store them in any file.
Storing the credential information in a file outside of your senhasegura management will leave the credential vulnerable to unauthorized access, and your queries cannot be traced, resulting in irresponsible use of the credentials.
Instruct the programmer to make a local cache of the credential, with lifetime control. This way, if the senhasegura is unavailable, momentary or not, the application will not stop running because it will have the local cache to query.
This practice can prevent tasks from being paralyzed and causing the unavailability of a vital service.
Match the lifetime of the local cache with the password rotation time of the senhasegura .
This way, the password stored in the local cache will not be outdated compared to the credential managed by senhasegura , making authentication impossible in case of unavailability since the password will be different.
Advise the programmer that in case the password returns a connectivity error to query the senhasegura again to verify that the password in question has not already been rotated. Remember that depending on the settings applied to the senhasegura the passwords may rotate frequently, so the local cache may become out of date.