Infrastructure Security

Our infrastructure runs on data centers provided by Amazon Web Services (AWS), which have several security measures in place. We adhere to AWS best practices, which are continously monitored and improved. There are several layers of infrastructure security, and access is role-based using AWS Identity and Access Management (IAM).

Authentication and Authorization

The Aera Payment & Identification (API) Gateway has several security measures to Authenticate (AuthN) and Authorize (AuthZ) Access to services (API endpoints) and data.

📘

Process of authorization

The process of authorization is distinct from that of authentication. Whereas authentication is the process of verifying that “you are who you say you are,” authorization is the process of verifying that “you are permitted to do what you are trying to do.” This does not mean authorization presupposes authentication; an anonymous agent could be authorized to a limited action set.

— Wikipedia

API Key

All API endpoints/services require an API key set as x-api-key header.

An API key is a unique identifier that is passed to the API to identify the caller and to authorize the use of the API. API keys are used to track and control how the API is being used, for example to prevent malicious use or abuse of the API. The API Key acts as both a unique identifier/authenticator and as a secure token for authorization, and has a set of access rights associated with it.

Access token

Most API endpoints require an OAuth access token in the Authorization header.

The API Gateway currently supports OAuth 2.0. OAuth2.0 is a simple and secure authentication mechanism. It allows application to acquire an access token/Json Web Token (JWT) for the API. Once an application has an access token, it will be given permissions to access services/endpoints according to the access policy.

Access Policy contains a list of policy statements. A policy statement stipulates whether to allow or deny the execution of the specified API method(resource). Access policy is generated based on a service agreement with Aera Payment & Identification AS.

OAuth access token and API key MUST be treated as secret data and NOT exposed to unauthorized parties.

The authorization setup is similar to what AWS describes in its article Introducing custom authorizers in Amazon API Gateway. Image from AWS:

Data Security

Data at Rest

All data is stored in managed databases which are regularly patched for security. Data is stored with at least dual redundancy with a minimum of 25 days of backups and is accessible only within the private cloud.

All data at rest are encrypted using strong encryption. Either by using client side encryption, encryption of storage or a combination.

Data in Transit

The use of TLS is mandatory, i.e. all requests MUST use the SSL endpoint. Aera Payment & Identification Gateway is enforcing TLS v1.2 on its end-points.

HTTP Data Integrity

In order to protect end-to-end data integrity, the HTTP response is signed and a digital signature is included at the JSON response object retrieved from the RESTful interface.

All RESTful responses have a Base64 encoded string in a response header named Signature. At retrieval of the HTTP Response the receiver should verify the integrity of the data. The signature has two purposes, prevent unintentional changes in information and unauthorized access (tampering) of data.
The current solution uses SHA-256 to create a hash digest of the full HTTP body. The digest is signed with our private key. We use RSA with a 2048 bits key. The signature is Base64 encoded. Use the pre-shared key to verify the signature.

The signature is only valid for the HTTP body and not the HTTP headers or URL.

Below is a simplified method that validates a signature

public boolean verifySignature(byte\[] payload, byte\[] signature, PublicKey publicKey) \{  
	Signature s = Signature.getInstance("SHA256withRSA");
	s.initVerify(publicKey);
	s.update(payload);

return publicSignature.verify(signature);\
}

Public Key of Staging Environment

\-----BEGIN PUBLIC KEY-----\
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv0Dmc
ZCsOF0Kvrg460utqCTM7EZcmr1p3aB+Mlqds5j7ID6epZQj/S
cfh5owlfPWcYaCpjY6OnF7SJHP5RqzQl9JI0YKcvFkDeu1nHA
6e5A7yhemHgjTS4iO0dHVfbcGlqELeragafNHZwKqqvu+ZYZt
vmOTseiLo//wRWlDUurBETAxjveLy1/BzUkFZRKPII8owU6U7
t3Jlrtwb6KontLm89SnUhXRe8HjXK1xN/2JA/q/YX4ketTWbV
0yi8jseGSfeNsDGApdXYsLoclYsbyOlVJXBVHOtqQoXNGd5dS
KTJ5dewsWXzeRmIWMvDFifzDsp+uWZQmF1/zsieJUrwIDAQAB
\-----END PUBLIC KEY-----\

Public Key of Production Environment

\-----BEGIN PUBLIC KEY-----\
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1tAzW
Ba9pY5WUfLLVpiL53BirmW144OGzgYrOWt5hQjZQevE6fuN3g
DhGjtNVHGx8Fn+im5IOwDo+1USYGIM15xzzmuRmEQ8jd8154I
Zu/TIhfhx+WbsTMVb0U0TfSrD8GFBgGt6IZnDR8k/jt0wYqEV
aoeZPRzkeGFfbUQXH446ZyolH+ATke8AtaWq8VKoqHNWS5FeO
Ydg2EGGmi0er3Kn6+9/XvIkx4KhrvKr0FdBoXXvaLOY/ZCa7o
S7zZ6rblHYDV1xHGEhcy1T+tkmg3ACX206FnNnsdBx21SdhBz
jjGSsUmS9Jkc2mzwxTk8ElJHlD56vLXGmnmYGSefQTQIDAQAB
\-----END PUBLIC KEY-----\

Data in Process

Access to the services are granted using API key and in most cases a JWT access token which are being validated. The data access/filtering is based on the subject’s scopes and data authorization.

Strict data validation is implemented on the request objects (size, range, constraints, etc.) to ensure the quality and correctness, in addition to prevention of injection attacks etc.

Input Validation

All input will be validated to ensure data quality and to avoid abuse or certain attacks of the services.

URL validations
Invalid URL, Parameters and Query strings will result in the server rejecting with "400 Bad Request" or "403 Request refused /Forbidden". See HTTP Error responses for more details.

Incoming Content-Type validations
APIs will never assume Content-Type, any unexpected Content-Type header will result in the server rejecting the content with a "415 Unsupported Media Type"

Incoming Content validations
APIs will never allow free-form content, any unexpected content, for example: invalid data type, invalid input format, invalid size of request, etc. will result in the server rejecting the content with a "400 Bad Request".

Response Types validations
The client can not specify the preferred order of response types by the Accept header in the request. If the Accept header does not specifically contain the allowable type, the request may be rejected.

Request Headers

Attack Prevention and Mitigation

/c

Aera Payment & Identification Gateway maintain intelligent API protection, firewalls, DDoS mitigation [on layer 3 og 4], etc., which along with the automatic scaling capacity of resources are designed to mitigate attacks at both the Application and Network layer.

Aera logs activity across the platform, from individual API requests to infrastructure configuration changes. Logs are aggregated for monitoring, analysis, and anomaly detection.

Aera’s developers are trained with specific attention towards security. The applications/developed code are being analysed automatically by several security and best practice tools, and human peer review is being performed. This is to ensure the best possible quality and security of Aera’s Platform. In addition, the Platform are regularly being security audited.

Security Incidents

If you’ve found a vulnerability in Aera’s services, please send an email to [email protected]. We will review it and respond as soon as possible.