Information Security is a top priority for Ardoq, and we also rely on the security policies and follow the best practices set forth by AWS.
Procedures will continuously be updated and improved.
Refer to Amazon Web Services Security policy (https://aws.amazon.com/security/) and the shared responsibility model that it’s the general principle that AWS is responsible for the security for the cloud services, and Ardoq is responsible for the security within the Application and the setup (https://aws.amazon.com/compliance/shared-responsibility-model/).
Ardoq follows Sans Application Security Policy: https://www.sans.org/security-resources/policies/application-security/pdf/web-applicationsecurity-policy
We implement a variety of security measures to maintain the safety of your personal information when you place an order or enter, submit, or access your personal information. We offer the use of a secure server. All supplied sensitive/credit information is transmitted via Secure Socket Layer (TSL) technology and then encrypted into our Payment gateway providers database only to be accessible by those authorized with special access rights to such systems, and are required to keep the information confidential. After a transaction, your private information credit cards will be kept on file for more than 60 days in order to pay for monthly subscriptions of the Service.
Ardoq is hosted on Amazon Web Services data center in Ireland or in the USA. It is possible to use other AWS Regions in a dedicated hosting solution.
All access from the internet to Ardoq is over HTTPS, and goes through an Elastic Load Balancer. Amazon security groups (virtual firewalls) ensure that traffic between the servers only happen on specific ports, both for incoming and outgoing connections. Learn more about Amazon security groups here: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_SecurityGroups.html
Only a few Ardoq employees have access to backend servers. All administration access to Ardoq servers go through a Bastion server. The Bastion server is only accessible when enabled through Amazon AWS Console, and can then be accessed with ssh private keys installed - username/password access is disabled. The private keys are stored in an encrypted vault, and added on the client only when needed.
Only a few Ardoq employees have access to the AWS dashboard. All access requires strong password and two factor authentication. Ardoq monitors logs from front-end, back-end and database in one centralized Kibana monitoring system. Ardoq also uses Amazon CloudWatch with monitoring and alerts of suspected breaches. Ardoq has configured AWS security groups, that limit cross component access to the minimum of required ports opened. Apart from this configuration, the firewall setup, maintenance and operation of the firewall is provided by AWS. Servers are updated and patched regularly.
The current main setup consists of load-balanced redundant front-end Nginx servers, load-balanced redundant API servers, and a cluster of databases. The servers are isolated from each other in separate security groups to increase security. For monitoring we run a set of monitoring servers with ElasticSearch, Logstash and Kibana. This gives us near real time insight into all requests. (User passwords and session keys are naturally not logged or monitored).
By invite only - on https://hackerone.com/ardoq.
All our servers are monitored using Monit to track performance and availability metrics. We also use Pingdom to track uptime, and alert us of service failure.
AWS Monitoring is setup to raise alarms for large quantities of data downloaded from Ardoq.
All our infrastructure is automated, so completely tearing down and setting up a fresh environment from scratch can be done in a matter of hours, excluding restoring of data.
All organizations are included in process for serious incidents, regarding both security and downtime. See 1.5.
Refer to Amazon Web Services Security policy https://aws.amazon.com/security/
Ardoq offers two options for user Authentication: i) Username and password ii) OAuth 2.0 Authentication using one of the following Identity provides: Google, Microsoft & Github.
Organizations subscribing to the Premium or Enterprise plan also have the option to use Azure Active Directory as their Identity provider.
Ardoq encourages customers to use OAuth 2.0 Authentication whenever possible. For customers who decided to authenticate using username and password, Ardoq follows industry best-practice for password storage. Passwords are salted and hashed using an adaptive oneway function (bcrypt) with high work factor.
Users in Ardoq are authorized to access resources belonging to an organization by being assigned a membership. Users can have membership in multiple organizations, and the level of access is governed by the memberships role within the organization in addition to a set of explicit access controls rights for each workspace.
Ardoq operates with three types of membership roles:
Admin - can edit all data within an organization and invite other members
Writer - can create, edit and delete data within an organization, but not invite other members
Reader - can only read data within an organization
In addition to roles, workspaces in Ardoq are protected by explicit access rights called workspace permissions. For writer roles, workspaces permissions have higher precedence than roles (a writer role might still only be granted read-access on a specific workspace). For reader roles this precedence does not apply (you can't give a reader role edit permissions on a workspace). Assigning rights to a workspace can be done by the user who created the workspace (the owner), or by an admin. Admins have full access to all workspaces in Ardoq, regardless of any workspaces access rights
Each request to Ardoq is bound to a context which specify the organization the request is trying to access. The context is defined by either a custom domain .ardoq.com (only available to enterprise plans), via a browser cookie or by a request parameter.
In addition to User Authentication, Ardoq offers a comprehensive REST-api. Users can decided to authenticate API-access using either HTTP Basic Authentication or HTTP Token Based Authentication. All API-access is associated with a user and given the same authorization as that user.
Ardoq encourages customers to use Token Based Authentication when accessing the API. Since separate tokens can be issued for different clients, if one suspect that a token is compromised, the user can delete this token and prevent access to Ardoq while leaving the other tokens active.
All organization data is stored in a separate database. In addition to the master database, the data is replicated to two slave databases.
Upon customer request, deleting organization data is simply a matter of deleting the database from master and slaves.
Secure deletion of data process:
Ardoq employs a continuous delivery pipeline. After merging code into master branch it automatically the pipeline builds, tests and deploys a new version of Ardoq. We deploy new features, patches and bug fixes multiple times a day.
Most changes and updates are applied in a rolling fashion, without down-time.
Scheduled down-time is notified in advance to all users via registered email addresses.
Ardoq is committed to security by design and secure coding practises. All production code is subject to the following coding policies
Ardoq release management follows the SDLC policy. We release features, patches and bug fixes as soon as they are implemented.