The following provides questions and answers on EJBCA SaaS operations. To view all questions and answers related to EJBCA SaaS, see EJBCA SaaS FAQ.


What are the outbound IP addresses for EJBCA SaaS?

AWS:

US Region (three gateways for three availability zones):

  • 52.15.174.51
  • 3.130.129.118
  • 3.139.10.5

AP Region:

  • 175.41.202.218
  • 54.65.165.163
  • 54.248.111.254

EU Region:

  • 13.48.197.125
  • 13.51.143.156
  • 13.51.140.111

Azure (Azure does not do individual gateways per AZ):

  • 20.84.213.69 - US deployments
  • 51.11.236.39 - EU deployments
  • 20.210.84.246 - AP deployments


What are the countries that EJBCA SaaS are operated per region?

Azure is:

  • Iowa (Central US)
  • France (France Central)
  • Japan (Japan East)

AWS is:

  • Ohio (us-east-2)
  • Sweden (eu-north-1)
  • Japan (ap-northeast-1)


Does EJBCA SaaS place limits on resource intensive operations? 

EJBCA SaaS is hosted on AWS or Azure which is designed to scale easily. Customers will be constrained by the size of the environment they have chosen.


How do I know my environment will be available whenever I need it? What is the SLA? 

The EJBCA SaaS Service Level Agreement is dependent on the size of your environment. For XS, the SLA is 99%. For S and M instances, the SLA is 99.95%. For L and XL instances, the SLA is 99.99%.


How are firewall rules created? How are they reviewed? And are firewalls set to “default deny = true"? 

Rules are created through Ansible/Kubernetes manifest files and the "default deny" setting is set to true by default. The rules are reviewed through a GitHub pull request. 


How are system resources, including network and storage resources, monitored? 

EJBCA SaaS uses AWS CloudTrail and Fluentd to collect logs from EJBCA in AWS. The logs are then fed into AWS CloudWatch for aggregation and monitoring.  In Azure, a similar method is used and the logs are fed into Azure Monitor.


How are incidents detected in EJBCA SaaS? 

AWS CloudWatch is used to detect any incidents in EJBCA SaaS in AWS and Azure monitor in Azure. Both of these logging systems are monitored by our EJBCA SaaS Operations team.


What if I want my data removed from EJBCA SaaS? 

Your satisfaction is our greatest concern. If you want your data removed, Keyfactor will remove your data from our product. However, Keyfactor requires the minimum amount of customer data to have the product function. If customer data is removed, the product will not function correctly.


How does EJBCA SaaS handle emergency changes? 

Emergency changes are handled through a hotfix workflow design in which changes are tested with required/functional validation and then quickly pushed to production in a fully automated fashion, but retroactively tested and approved in the staging environment. Keyfactor has it set up so that we have to have successfully deployed to test before you can push a new release to production.


Does EJBCA SaaS have a formal, structured change management process? 

Yes, Keyfactor deploys to test and production via pipelines in GitHub actions to develop, test, approve, and then push changes to production.


How does EJBCA SaaS achieve HA?

EJBCA SaaS leverages multiple availability zones within its infrastructure. All compute operations within the EKS/AKS(Kubernetes), HSM and database infrastructure leverage at minimum two availability zones. All EJBCA SaaS deployments implement a read-only replica of the dedicated, per-deployment database for reporting purposes that can also be leveraged for DR purposes in both AWS and Azure.