RODPAY
Architecture & Security
1. Introduction
Rodpay is a pioneering company dedicated to facilitating Bitcoin transactions for merchants through the innovative Bitcoin Lightning Network. Our offerings include POS devices, as well as versatile apps capable of transforming smartphones into efficient POS terminals. We Provide a robust API that empowers online stores to seamlessly integrate Bitcoin payment acceptance into their systems, providing customers with a convenient and secure way to make transactions
2. Infrastructure
RODPAY is based on software that requires computing, communications and data storage infrastructure and services to run.
2.1 Public Cloud and PaaS Services
Why is RODPAY based on a public cloud? The answer is that public clouds simplify or almost eliminate the management and maintenance needs of infrastructures, because they provide very fast scalability and the high level of availability of their services. Why is RODPAY based on PaaS services? RODPAY, which is itself a SaaS service, is almost entirely based on Azure PaaS services. It was decided to use PaaS services because the level of anagement and added value for developers are the highest and with less administration effort, better final results are achieved.
2.2 Our PaaS provider: Microsoft
Obviously, the quality of the infrastructure and services directly impacts the performance and quality of RODPAY. In other words, the choice of a reliable PaaS service provider is crucial for the characteristics of the services provided based on it.
The criteria applied to select Azure were:
- Power and variety of PaaS services
- Complete and powerful developer ecosystem.
- Ability to transparently encrypt data at rest.
- End-to-end data encryption capability.
- Compliance with legal regulations, standards and certifications.
- Possibility of choosing the geographic region of the underlying physical resources used.
- Replication of services and data.
- Automated scalability through rules
- Cloud health monitoring systems.
- Possibility of applying firewalls at the different levels where required.
- Managed backup and restoration services.
- Managed key and secret custody mechanisms
- Managed identity management and authentication mechanisms.
- Renowned and solvent supplier company
2.3 Azure Standards and Certifications
Compliance with quality, safety and legal regulations standards is an essential guarantee in the infrastructures of a cross-cutting process automation service such as RODPAY.
It must be said that the set of Azure certifications and standards is constantly growing and currently consists of more than 90 certifications.
Below are just a few of the most significant in the European Union space:
You can review all certifications and compliance standards at https://azure.microsoft.com/en-us/overview/trusted-cloud/compliance/ .
2.4 Service levels
Azure has excellent guaranteed service levels. SLAs in Azure are specified service by service, so there are many specifications that can be consulted at
https://azure.microsoft.com/en-us/support/legal/sla/summary/ .
With all this and adding our own maintenance program, RODPAY currently offers 99% uptime.
3. Architecture
As already mentioned, the organization of the software and infrastructure, i.e. the architecture, is totally decisive for the final characteristics of the service, such as scalability and security. RODPAY’s architecture is designed with the aim of being able to absorb sudden large workloads and to guarantee security and confidentiality for each of the clients while maximizing the use of all infrastructures. RODPAY is a SaaS that is based on PaaS cloud services. There are many SaaS whose infrastructures are not based on cloud services, so in reality their scalability and security are dubious, but this is not our case! All the PaaS services used by RODPAY are provisioned in the Microsoft cloud, which is called Azure.
3.1 RODPAY Architecture Diagram
The following diagram shows the different subsystems that make up RODPAY as well as the relationships between them. The following sections explain each of the subsystems in more detail, especially those that affect security and scalability
RODPAY Architecture Diagram
3.2 Service Layers
RODPAY’s architecture is organized in layers, among other reasons, to improve security and control. All subsystems have been arranged in three layers:
Customers’ Layer: There are three types of interaction solution to RODPAY system.
- Web Interface: RODPAY provides web interface that can be used to create accounts and manage transactions, POS devices
- Mobile Interface: RODPAY provides a mobile interface that can be used to manage Bitcoin Lightning transactions. There are two types of mobile app - POS Device app and normal mobile device app
- API Interface: RODPAY Provides API Integration service to allow customers integrate RODPAY Service into their own services.
Backend Server Layer: In Backend server, it receives all requests from Customers’ Layer and interacts with BTCPay server to organize and manage Bitcoin Lighting transactions, and save all necessary data to DB
BTCPay Server Layer: In BTCPay server, it opens channels with all the famous Lightning Nodes and makes transactions between them to manage customers’ requests.
3.3 Replication of processing services
Processing subsystems (VMs) are composed of at least two instances for better fault tolerance. This allows minimum service levels to be guaranteed by having backup processing capacity that may be required due to the failure of one of the instances or due to load increases.
Under normal circumstances, having all processing subsystems at least duplicated improves availability by avoiding the delay of automatically or manually scaling available resources.
3.4 Scalability
Scalability is the ability of subsystems to adapt to the workload required by RODPAY. It is key to maintaining RODPAY’s performance and essential to ensure the highest availability of the service. Azure allows us to scale quickly, automatically and/or manually.
3.4.1 Automatic Scalability
We use it primarily to provision processing subsystems. It is based on configurable rules that can use different metrics to be adjusted. In most cases we use rules based on % of CPU usage, although we also have rules based on task queue length. The type of rules to use in automatic scaling is closely related to the way we balance the loads of each subsystem.
3.4.2 Manual Scalability
In the case of the database, there is no rule that automates its scaling; it is done manually by a technician. This involves entering the Azure resource management console and performing the scaling operation manually.
However, it must be said that the Operations Department has a monitoring and early warning system to anticipate short, medium and long-term overload events.
3.5 Data encryption
Data is an increasingly vital asset for any corporation. Its confidentiality is vital and RODPAY protects it by encrypting it both when storing and transferring it.
3.5.1 Data Encryption at Rest
We call data at rest those that are in storage waiting to be processed, that is, those that are on an optical, magnetic or solid state disk, or similar. Data at rest is highly vulnerable since if no measures are taken, it could be read by connecting the physical device to another workstation. This could occur with storage units even at the end of their useful life if they are not properly destroyed.
To avoid any confidentiality issues, all data at rest is stored encrypted, so that even if it were accessed, it could not be read. Encryption is applied to both structured data (databases) and binary files (document versions, graphics, attachments, etc.).
To perform encryption, transparent encryption services are used that Azure provides specifically for this purpose.
3.5.2 Encryption of data in transit
Data transferred to and from services, systems or clients outside the RODPAY perimeter is encrypted with 256-bit certificates using the https protocol.
3.6 Storing binary files
In RODPAY, a significant portion of the data stored is stored in binary files. For example, account information, images, templates, etc. are stored in binary files. Binary files are stored in Azure storage accounts.
3.6.1 Transparent replication of binary files
Azure storage accounts offer replication capabilities, meaning that two copies are maintained in real time. All of this occurs transparently for users and also for the manufacturer. At RODPAY we have all binary files replicated using this mechanism, providing an additional guarantee. Transparent replicas are not directly accessible and can only be used in case a restoration is required.
3.6.2 Functional replication of binary files
In addition to the transparent replica, RODPAY employs and maintains an additional replica, which we call functional since it is accessible and usable at all times. A characteristic of the functional replica is that it is located in a storage account located in a geographical area far from the main account.
Functional replication provides higher availability and fault tolerance, since even if the main binary file store is offline, normal operation can continue.
Only the simultaneous failure of both replicas would force RODPAY to stop. In the event of a failure of one of the stores, either the replica or the main, the coherence between both will be restored with a batch synchronization process without any interruption of the service.
4. Governance
4.1 Backup Policy
A vital part of the service offered is the safekeeping of data and documents. Preserving them in the event of infrastructure failure means guaranteeing the continuity of the service. To do this, we have procedures for backing up structured data information, which is stored in a database, and binary information such as documents, images, etc.
It should be noted that backups, while vital for system recovery in the event of a disaster, must comply with data protection law, so certain limitations apply.
4.1.1 Structured Data Backups (DB)
4.1.1.1
Ability to retrieve the status of the database continuously over time The database PaaS service we use, Azure SQL, has the ability to restore itself to the state it was in at any point in time in the last 14 days. That is, we can reconstruct the state the database was in at any point in time in the last 14 days.
4.1.1.2 Backups by exporting the database
As a complement to what is indicated in point 4.2.1, multiple backup copies of the database are made, as protection in case of catastrophe. More specifically, the backup policy is as follows:
- Weekly copy. The last 4 copies are saved.
- Monthly copies. The last 12 copies are saved.
- Annual copy. Only one copy is saved, the one from the previous year.
4.1.2 Binary Data Backup (BloB Storage)
The service we provide does not allow modification of said binary files, so in the storage of binary files only files are added or deleted, which is why an Incremental Backup system of the binary files has been implemented.
Incremental backup is launched daily, and this means that the binary files backup is incremented each day with the new binary files received that day.
4.1.2.1 Monitoring binary file backup
To ensure that a backup copy of the binary files is available, a process (run daily) is available to compare the backup and transactional containers. If any discrepancy is detected, a warning is issued so that the operating team can resolve it.
4.2 Service Updates
The software on which GladToLink is based is developed in-house and is updated frequently. The deployment of modifications must be done in a predictable way, so that users who apply GladToLink in critical missions, if they wish, can make their own contingency plans, tests parallel to those we carry out ourselves. In this section, the procedures for deploying the platform and other elements of the ecosystem are important.
4.2.1 Platform www.rodpay.com
4.2.1.1 Maximum refresh rate.
Except in cases of extreme urgency, no more than one biweekly update will be made.
4.2.1.2 Communication to users
Communication will be made about each new version, modifications, fixes made and the degree of importance of updating it. As for the channels for communication, they could be email, news feed, notice on login page. Pending clarification of the channel
4.2.1.3 Manual Scalability
The list of changes and fixes that accompanies a new version should be focused on users, so it should be sufficiently clear and exhaustive. I would like to emphasize exhaustiveness in particular, even the smallest bugs that have been fixed should be reflected.
4.2.1.4 Deployment dates.
New platform versions will always be deployed on Tuesdays of the first and/or fourth week of the month. This excludes weekends…
4.2.1.5 Quality control.
A battery of tests will be carried out before a release is announced. Under no circumstances will developers who have participated in the release be able to participate in quality control.
4.2.1.6 Authorization.
Any new version must be previously authorized by the CTO or, failing that, by the CEO. Even critical versions that require urgent deployment must be authorized.
4.2.2. Mobile APP
4.2.2.1 Maximum refresh rate.
Except in cases of extreme urgency, Mobile App will not be updated more than once per fortnight.
4.2.2.2 Early provision.
New versions of Mobile App will be made available to users one week before the scheduled release in stores. This will give them a margin to manage the update and testing process.
4.2.2.3 Communication to users
Communication will be made about each new version, modifications, fixes made and the degree of importance of updating it. As for the channels for communication, they could be email, news feed, notice on login page. Pending clarification of the channel.
4.2.2.4 Release documentation
The list of changes and fixes that accompanies a new version should be focused on users, so it should be sufficiently clear and exhaustive. I would like to emphasize exhaustiveness in particular, even the smallest bugs that have been fixed should be reflected.
4.2.2.5 Publication dates.
New app versions will always be released to stores (Google Play Store and App Store) on Tuesday mornings in the second or fourth week of the month. This excludes weekends…
4.2.2.6 Publication in stores.
The scheduled publication mode will be used, that is, never with immediate effect
4.2.2.7 Quality control.
Before announcing a version, a battery of tests will be carried out. The battery of tests is pending definition. In no case will developers who have articipated in the version also be able to participate in quality control.
4.2.2.8 Authorization.
Any new version must be previously authorized by the CTO or, failing that, by the CEO. Even critical versions that require urgent deployment must be authorized.
4.3 Account Management, Authentication and Permissions
An important aspect of security and confidentiality is how identities are managed, what authentication mechanisms are like, and how permissions are managed. This section details these issues for users (clients) of the platform and also what access and capabilities the RODPAY staff has.
4.3.1 RODPAY Personal
The management of the manufacturer’s own personnel’s permits is one of the logical concerns of our clients and this section explains the fundamental lines of action in this regard.
Regardless of the technical aspects or permissions granted in each case, there is always a confidentiality agreement between all members of the staff and the company
4.3.1.1 Managing RODPAY Staff Account Authentication and Permissions
It is done through the Azure Active Directory, which is vital to ensure the confidentiality of each of our clients. Therefore, it is managed based on the function that each person performs (role) and/or what special situations may require, such as debugging needs, migrations, etc.
The policy applied is restrictive, that is, everything is denied by default and the minimum necessary permissions are granted to the minimum number of people possible.
4.3.1.2 RODPAY Staff Roles and Production Environment Access
The following table explains what each RODPAY staff member can access.
| Production database | Binary Files | Infrastructure Production | |
|---|---|---|---|
| CEO | No | No | No |
| CTO | Yes (1 person) | Yes (1 person) | Yes (1 person) |
| CISO | Yes (1 person) | Yes (1 person) | Yes (1 person) |
| PROJECT MANAGER | Yes (1 person) | Yes (1 person) | Yes (1 person) |
| DEVELOPERS | No | No | No |
| BUSINESS CONSULTORS | No | No | No |
4.3.2 RODPAY Customers
4.3.2.1 Customer account management and authentication
Each client is free to manage their employees’ accounts on RODPAY, including creating, deleting, blocking, resetting passwords, etc.
Account management and employee authentication can be performed from the RODPAY portal (native system), or through integrations with active directories on premise (already available) or in the cloud (in development).
RODPAY has IP filters and time restrictions in place for its operations. These are fully manageable by the client from the RODPAY portal and can be applied to individual accounts or all of them.
4.3.2.2 Managing Client Account Permissions
Each client is autonomous in managing the permissions of their employees’ accounts.
Permissions can be set as granular as you like, from preventing an employee from sharing any document to granting permission to intervene in a workflow to produce a very specific state change. For details on how to do this, see the appropriate blog posts
5. Service Supervision
RODPAY is a service monitored at all its levels and subservices by the Operations Department. Health and performance control of all elements of each level and subservice is carried out using the tools provided by Azure. More specifically, the Azure monitoring and alarm management system is used.
5.1 Monitoring
Azure monitoring system is used to monitor all subsystems at the level of CPU consumption, memory, consumed resources, I/O, cloud health, work queue size, …
5.2 Alarms and Logs
There are many alarms configured to anticipate problems. In addition, there is a log of all alarms and other events of interest that are reviewed periodically.
5.3 Third-party vulnerability testing
A vulnerability analysis system has been contracted from an independent provider of RODPAY, also from Microsoft, with recognized effectiveness
https://es-la.tenable.com/ . The result of the last scan as of March 31, 2020 is attached below in this same document as ANNEX I.
As a policy, we publish this report annually, and the vulnerabilities that are detected are resolved. It is a continuous and obligatory task to improve the security of our platform on a daily basis.
As ANNEX II we include the compliance report of the AZURE security guide as of today, February 15, 2020, which we update monthly.
