05 May, 2016
Security is a prime concern for companies deploying data and solutions in the cloud. innius is a cloud-based solution with a prominent mobile component. When we decided to build innius on the Amazon Web Services (AWS) platform, security was a main consideration. We also created additional layers of data protection in the solution. Let’s take a look at the architectural basics of innius security.
Building on Amazon Web Services standards
AWS Cloud Security, the primary building block for innius security, offers a wide range of security features to maintain the integrity of your data and applications in the cloud. AWS data centers are highly secure, and the AWS infrastructure includes a large number of compliance programs to ensure security measures in line with companies’ policies. The global AWS infrastructure comprises five functional regions of data centers, with new facilities about to come online. In response to an event that jeopardizes data and application security, AWS clients can choose to have replication occur between data centers within the same region or among regions. Machine data from innius are stored at an AWS data center in Ireland.
innius follows security best practices for AWS environments. We support the AWS Shared Responsibility Model. In this architecture, the security of the cloud, such as data centers, infrastructure, computing and networking resources, and data storage, is the responsibility of AWS. The client is accountable for the security in the cloud, which comprises such elements as data, applications, operating systems, and the configuration of firewalls and networks.
Protection for innius’ main components
innius cloud services, which incorporate representational state transfer (REST) technology, each offer a RESTful web service interface with public as well as protected endpoints. The latter require an authenticated as well as an authorized caller. Authentication requires a security token for the innius authentication service. A service queries the innius authorization service to verify that a caller is in a security group associated with a security policy.
The innius mobile and web components integrate with Auth0, the widely used authentication solution, for user logon and user token acquisition. They also deal with token expiration and invalidity, and respond to http errors. The two apps cache tokens on a device for ease-of-use and better performance, but those may be revoked or can expire at any time.
When it comes to the integration between innius and customers’ machines, our customers are responsible for the acquisition of machine industrial internet of things (IIoT) data. However, a machine token we issue secures the connection with the innius cloud, which happens using SSL/TLS protocol. Batch data upload takes place according to AWS S3, using SSL/TLS and pre-signed URLs. innius performs real-time data uploads according to AWS Kinesis, using SSL/TLS and temporary AWS STS security tokens.
As regards the integrations between innius and ERP, PLM, CMMS, and other back-end systems, they come about through the RESTful APIs of the different microservices, and are secured in the same way as other innius integrations. As authentication tokens, innius generates API tokens for specific companies and particular user identities within the companies. Data is transferred over the internet on SSL/TLS-secured connections. As much as possible, innius selects standard cryptographic algorithms for hashes, checksums, and encryption with key sizes recommended by security experts.
In upcoming posts, we will discuss three core areas of security in more detail: how innius handles identification, authentication, and authorization, how it ensures the integrity of data and data exchanges, and how it enables the availability of data and applications.
If you would like to explore innius more practically, have questions, or want to provide feedback, please contact us.
Follow us
