Data Security and Durability

The HERE platform protects your data using security and durability best practices.

Security

The HERE platform utilizes industry-standard data security best practices to protect your data:

  • Data stored at rest in versioned layers, stream layers and index layers is encrypted using AES-256, a strong, proven, block cipher. This data protection includes data which has been persisted per the Time to Live (TTL) setting. Data stored in volatile layers is not encrypted.
  • Data in transit between the platform and your applications is encrypted using the TLS 1.2 cryptographic protocol and the strong AES-256-GCM cipher.
  • Within the platform, data in transit is also encrypted using TLS 1.2. Additional or different protection mechanisms are employed as needed.
  • HERE secures the platform website and API endpoints with trusted certificates issued by a well-known Certificate Authority (CA) and signed using a SHA-256 algorithm.

If you intend to cache private or sensitive data on an edge device, be aware that the data may be cached on the device without any protection. So, when the data is uploaded to the HERE platform, the data owner should encrypt any sensitive data before it is uploaded. This way, when the encrypted data is downloaded from the platform to an edge device, it is cached in encrypted form. The application on the edge device can then decrypt the data and consume it, but the data is protected while cached.

Learn more about HERE's compliance practices and certifications: https://legal.here.com/en-gb/compliance

Durability

Your data is protected from loss due to corruption or system failure. The degree of durability depends on the layer type.

Versioned Layers

Versioned layers are designed to provide 99.999999999% (11 nines) durability of data (both data and metadata) over a given year. This durability level corresponds to an average annual expected loss of 0.000000002% of data (blobs) and metadata (partitions). Data is stored in a single region by default, and versioned data is stored redundantly on multiple devices across a minimum of three independent network and power domains within that region.

Index Layers

Index layers are designed to provide 99.999999999% (11 nines) durability of data over a given year. This durability level corresponds to an average annual expected loss of 0.000000002% of data (blobs). Data is stored in a single region by default and redundantly on multiple devices across a minimum of three independent network and power domains within that region. Index metadata is stored in a single region by default and redundantly on multiple devices across a minimum of three independent network and power domains within that region with an aggregate durability of 99.99998% (6 nines).

Volatile Layers

Volatile data is temporal. Existing data is overwritten every time new data is written to a partition. Data redundancy depends on the layer configuration option selected:

  • For multi-instance configured layers, data/metadata is stored redundantly on multiple devices across a minimum of three independent network and power domains within a single region. Failure of one device would be recovered by another.
  • For single-instance configure layers, data/metadata is stored only once on a single device within a single region. Failure of this device may result in irrecoverable loss of data.

For more information on volatile layer data redundancy, see Data Redundancy.

Stream Layers

Stream data is replicated across multiple devices and across three independent network and power domains within a single region. Failure of one device will be recovered by another. Additionally, stream data is always written to an underlying filesystem. You can set how long this data is retained in the filesystem by using the TTL (Time To Live) setting. A best practice is to configure the stream data TTL long enough to ensure that data is not dropped in the event of a consumer group interruption (e.g. a pipeline restart) and while corrective actions are taken.

In addition to these data redundancy measures inside the HERE Workspace, the recommended best practice is to ensure regularly tested backups exist. Secure data backups, in the form of one or more duplicate catalogs, can be assigned a narrower set of permissions to further limit who can delete those backups.

(Optional) Multi-Region Replication

When configuring a catalog, you can select the multi-region feature (“store in backup region”). When you create a multi-region catalog, the platform automatically performs all of the necessary tasks to propagate ongoing data changes to a secondary region.

Data stored in a multi-region catalog is stored in western Europe as the primary region and the western United States as the secondary region. The platform does not currently support the ability to customize which region is your primary or secondary region. In the event that the primary region goes down, your data will be available via the secondary region but you should expect higher latencies depending upon where your data requests originate.

This capability currently supports availability of the service for the following layer types and operations ONLY:

  • Reads against versioned layers.
  • Reads and writes against volatile layers.
  • Reads and writes against stream layers.

Since only versioned, volatile and stream layer operations are supported at this time, multi-region catalogs can only have versioned, volatile and stream layers added to them. You cannot add index layers to a multi-region configured catalog.

Due to the different use cases for versioned layers (stable data), volatile layers (fast changing data) and stream layers (continuous stream of messages), different consistency guarantees and data replication strategies apply:

  • For versioned layers:
    • HERE Workspace uses a synchronous data replication process. This replication process adheres to read-after-write consistency where data is acknowledged only when it is successfully written to both regions. The synchronous replication process means that writes to versioned layers are possible only when both primary and secondary regions are available. During a regional failover event, it will not be possible to write any new data while the primary region is down. All data already written prior to the incident will be available to read in either region.
    • There will be additional latency for the platform to copy data into the second region which will be impacted by the size of the data.
  • For volatile layers:

    • HERE Workspace supports eventual consistency guarantees with asynchronous copying of data to another region. Data is acknowledged when written to the primary region, then it is written to the secondary region as long as connectivity exists. If the platform cannot write to the second region when the primary region is down, data loss will occur.
    • Additional information about volatile layer data redundancy can be found here: https://developer.here.com/documentation/data-user-guide/user_guide/portal/layers/creating-volatile-layer.html
    • The replication process should not adversely impact write latency but there can be a delay (replication time) for data to appear in the second region, depending on internet connectivity and size of the data.

      Warning

      If you are publishing data during a regional failover, the volatile metadata stored in the secondary region will not replicate back to the primary region. We recommend not publishing volatile metadata until you have a full recovery. HERE is working to address this issue.

  • For stream layers:
    • Data is replicated asynchronously to the second region once the data is written to and acknowledged in the primary region. Data written to the primary region but not yet replicated to the secondary region before a regional incident/failover event will be delivered once the primary region recovers. Any new data written after a failover event will be written to the secondary region – as the new primary.
    • The replication process should not adversely impact write latency but there will be replication time which depends on throughput, connectivity to the other region, and size of the data.

If you enable multi-region replication, you’ll be charged for additional storage capacity and data I/O:

  • Your storage charges (Blob, Volatile, Stream, Stream TTL, Metadata) will double to reflect the storage of data in a second region.
  • Your transfer charges (Data IO) will increase 2.5 to 4 times, depending upon the size of the objects you’re uploading: less for fewer large objects, more for many small objects.

To enable multi-region, you must specify a replication region when you create the catalog. This multi-region configuration is immutable so once a catalog is created as a multi-region catalog, you cannot change it to be a single region catalog.

results matching ""

    No results matching ""