{"id":6140,"date":"2021-03-18T09:44:07","date_gmt":"2021-03-18T09:44:07","guid":{"rendered":"https:\/\/sofialocks.com\/security-and-data-protection\/"},"modified":"2026-03-30T07:03:39","modified_gmt":"2026-03-30T07:03:39","slug":"security-and-data-protection-psti","status":"publish","type":"page","link":"https:\/\/sofialocks.com\/en\/security-and-data-protection-psti\/","title":{"rendered":"Security and Data Protection (PSTI)"},"content":{"rendered":"\n
\n
\n
\n
\n

OPEN SOURCE TO SUPPORT SECURITY<\/h2>\n\n\n\n

We believe it is strategic to rely on widely maintained and consolidated Open Source software components, avoiding where possible custom solutions that are difficult to maintain and not extensively tested. The “not invented here<\/em>” and “security through obscurity<\/em>” approaches are not part of our culture, even more than our systems.<\/p>\n<\/div><\/div>\n<\/div>\n\n\n\n

\n
\n
\"\"<\/figure>\n<\/div><\/div><\/div>\n<\/div>\n<\/div>\n<\/div><\/div>\n\n
\n
\n
\n

INFRASTRUCTURAL AND APPLICATION BEST PRACTICES<\/h2>\n\n\n\n

Reliability, scalability and security were the reasons that led us to choose the market-leading Cloud Provider as a reference partner for our Cloud systems. The security of applications released on AWS is ensured by adopting the best-practices recommended by the same Cloud Provider, from data encryption (at the database level in the first place, as then on object storage and in any other data medium “at rest<\/em>“) to communication between services (always on internal VPCs, and strictly over secure SSL channel), and user authentication (via standard OAuth 2.0 for system users, and enterprise single sign-on with multi-factor authentication for the employee intervening on the infrastructure).<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n

\n
\n
\n

INFRASTRUCTURE-AS-CODE E RESILIENCE<\/h2>\n\n\n\n

The entire infrastructure is managed through a “declarative approach” in the definition of resources and their configuration: this enables robust automatic “disaster recovery<\/em>” procedures, which allow to minimize the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) in case of distributed failure. We tend to periodically test these procedures to ensure that they are up to date and correct, commissioning periodic assessments to Cyber Security consultants outside the organization, to validate the technological choices and measures implemented to defend the platform perimeter.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n

\n
\n
\n
\n

PROTECTION OF THE COMPANY PERIMETER<\/h2>\n\n\n\n

The security of company computers and devices is guaranteed through disk encryption, biometric identification of the employee and complete remote management of the device fleet. Personnel authentication for access to internal and external company services takes place, where technically feasible, via Single Sign-On (SSO) via Google Suite Business: this guarantees us a single point of access to corporate communications and systems , with strict policies on password renewal and multi-factor identification. The access keys to systems that do not support integration with our SSO Provider are shared through a dedicated secret management service, which in turn can only be accessed via corporate SSO. <\/p>\n<\/div><\/div>\n<\/div>\n\n\n\n

\n
\n
\"\"<\/figure>\n<\/div><\/div><\/div>\n<\/div>\n<\/div>\n<\/div><\/div>\n\n
\n
\n
\n
\n

DATA PARTITIONING AND SECRET MANAGEMENT<\/h2>\n\n\n\n

The production and development environments are physically and logically independent, allowing us to severely limit access to real user data to strictly authorized personnel only for application and infrastructure maintenance activities. The application code and the secrets necessary for accessing the systems are always managed independently, using automatic procedures for the reconciliation of references to secrets during the software release phases in their respective environments. The use of a reliable and centralized secret management service (based on a “zero knowledge<\/em>” architecture) allows us to automate the management of access keys and their periodic rotation. <\/p>\n<\/div><\/div>\n<\/div>\n\n\n\n

\n
\n
\"\"<\/figure>\n<\/div><\/div><\/div>\n<\/div>\n<\/div>\n<\/div><\/div>\n\n
\n
\n
\n

AUDITING & DISTRIBUTED LOGGING<\/h2>\n\n\n\n

Any user activity in the system is tracked through application and system logs: on the one hand, activity tracking can help with troubleshooting, providing an accurate history of the activities performed and the respective responsibilities of developers, system administrators and\/or end users; on the other hand, guaranteeing the compliance of our platform with the most recent rules imposed by the GDPR.<\/p>\n<\/div><\/div>\n<\/div>\n<\/div>\n\n

\n
\n
\n

FURTHER CONSIDERATIONS ON THE GDPR ISSUE<\/h2>\n\n\n\n

All the activities described so far guarantee the safety standards required by the General Data Protection Regulation (GDPR) at any stage of the development and maintenance of the system. In addition to the technical choices aimed at minimizing the risk, the processing of the data is guaranteed with respect to the principles of lawfulness set out in the Regulation, in particular: <\/p>\n\n\n\n