These answers focus on the technical aspects of Jetty.
For further answers, please contact our team directly.
How Jetty handles various aspects of security:
Q: How are data and code protected from external intruders?
A: Well beyond the typical standards for username & password, the data is stored on an encrypted database cluster. It is effectively unavailable from outside Amazon Web Services (AWS), which we are using for the hosting of the Jetty Tools. We have set rules to limit outside access to our 4 IP addresses world wide. As for services we use within AWS, they also require rules to allow access to the data because by default, they are denied access. The web server, on which the code is run, only accepts HTTPS-requests on a specific port. Then it is directed to the API, which is used to serve data to clients. This type of request cannot affect the file system that the code resides on. It is not possible to access the server using SSH or FTP without additional steps being taken to configure the servers by the administrator. When updating the code, it is automatically fetched from a 2-factor authenticated, private Gitrepository on Github over HTTPS. No code can be directly deployed to or edited on the server. The Github repository is only accessible by the development team at Swace Digital. Any updates to the code must be approved by a senior developer before being accepted into the code that is eventually deployed to the server.
Q: How is traffic protected?
A: All traffic to and from the Jetty tools is encrypted using the latest Security Socket Layer (SSL) standards. This means that all traffic uses HTTPS, and it is the only way to connect to the Jetty Tools. https://strongarm.io/blog/how-https-works/
Q: How is Jetty equipped to handle scaling or expansion into other regions?
A: Using Fargate within AWS, the actual application containers are duplicated when more copies are needed in order to handle the increased demand. As more containers are created, the load balancer will spread the load out between the running containers. The database cluster works in a similar way. All information is written to a primary database, but the cluster can have many nodes serving up the information via another load balancer. In regards to handling other regions, we are able to setup the exact same functionality in any region supported by AWS. We can do so within a short amount of time and just a few tweaks to the code itself. This would allow us to expand and have all data stored within the selected region as well. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html
Q: How are client websites or device based apps connected to Jetty?
A: All traffic, not just client’s websites and our apps, are fed information via an API built at the heart of Jetty. By default, the API and what is served out by it is limited to the local container. However, with the API, we are able to decide to make certain things accessible to the outside with relative ease, such as websites and apps. Accessing the API also requires a form of key as well as permissions within the system itself in order to function properly.
Q: Are Jetty login attempts logged?
A: We log all failed login attempts along with information that would help us to block future attempts, should it be deemed necessary. We also log limited information of successful login attempts for future reference, should they be needed.
Q: How is data backed up?
A: Using the Amazon Aurora Relational Database Service (RDS) from AWS, we have continuous backups and point-in-time recovery. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_AuroraOverview.html
Q: What redundancies are set in place to protect against hardware failure?
A: Instead of using a dedicated server setup, Jetty is run off a number of the key services provided by Amazon Web Services (AWS). All of the services that we use are setup with failover capabilities or employing the redundancies built-in their services.
Q: How do we protect against malicious code?
A: Jetty is protected against code injection in a number of ways. Data, entered by users and sent to the backend, will be automatically escaped by the Symfony Framework and, on a database level, by the ORM Doctrine to protect against SQL-injections. No data is sent between clients except by way of the database, which means that no cross-site-scripting can take place. All data input by users is only presented within HTML-tags, never in tag-names, HTML-comments or any other unsafe place. All script-tags are filtered on the frontend and will never be sent to the server to begin with.
Q: How do we monitor performance and up time?
A: Using the AWS CloudWatch service, we are able to easily monitor all the key pieces involved in making Jetty work the way that Jetty works. CloudWatch also can notify us of any potential issues that could cause outages. We also have a number of external monitoring services, such as Sentry that provide logging and notifications of potential issues with the code itself to help us continually improve things. With more recent upgrades made to our setup within AWS and way of hosting, we continue to improve our ability to handle sudden large bursts of demands on any part of the system.
Q: How do we document changes/updates that are made?
A: All changes made to the code are paired together with information about the time it occurred and who the author is. This information is in the distributed version control system Git and stored centrally on Github.
Q: What is our process for updates or bug fixes?
A: Basically the majority of all code changes are made as part of larger development sprints. These are clearly defined sets of development tasks resulting in new features or improved appearance or functionality of existing parts of the system. Development sprints are often complemented with graphical design. Bugs listed using internal tools, such as Teamwork and Slack, are mainly collected in two ways: • Users get in touch with the Jetty team regarding a suspected bug or unexpected behavior in the system. This information is then provided to the development team through Slack. • Jetty uses the crash monitoring service Sentry. This service is activated when something in the system breaks. The user is then presented with a popup in which they can describe the actions they took before the crash occurred. An issue is then automatically created in Sentry where it can be easily searched, reviewed and resolved by the development team. The collected bugs are, depending on severity, resolved in batches by the development team during planned bug-fixing sessions.
Q: How is testing completed before deployments?
A: Jetty is quality assured by both programmatic tests and human testing. Before any code can be committed to Github, it is automatically tested by the external service Travis which makes sure that the API always returns correct data on all endpoints and that the frontend builds correctly. Before any major deployment, the system is tested on one of several development servers that are exact clones of the production environment. The testing is carried out by both members of the development team at Swace and Jetty team members.
Q: How is documentation kept?
A: Documentation describing how to set up, run, maintain, and develop the system is kept up to date by the development team on an internal wiki.
Q: How is media stored?
A: All files uploaded to the system are stored on the AWS Simple Storage Service (S3). Unless specifically made publicly accessible by the user, all files are protected by use of pre-signed URLs. https://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html
Q: Is Jetty GDPR compliant?
A: Yes. Please visit our GDPR-page for general information. If you have specific questions, please contact us at hello@jetty.se.