The Journey to Secure Part 2 – FYI

Guest post by Byron Pogson, Senior Solutions Architect, AWS 

This week on the AWS Startup Blog, we have stories from two customers who share their how they added security into their products on AWS. We recently shared the story of Tic:Toc, a digital home loan scale-up based in Adelaide, Australia, and the steps they took to set their initial foundations. Once your foundations are in place, having a process in place for assessing your architecture is important in building on top of that foundation. To learn more about how customers are evolving their security posture, we sat down with Alan McLeod, the CTO at FYI.

FYI is a startup founded in 2016 that provides cloud document management and process automation for accounting practices. They also provide integrations with accounting platforms such as Office 365, Xero and other account applications. Accounting practices  FYI to store sensitive information so the security of the system is a key factor in their design decisions. You can learn more about their comprehensive approach to data security, reliability and future-proofing the platform on their website.

After they had built out their product, FYI engaged with AWS for a review of their architecture ahead of the launch. During this process the focus was on ensuring that they had built for security and consistency. As a process for assessing their architecture we used the Well-Architected Framework. If you’re not familiar with the Well-Architected Framework, it’s a series of questions and tools to help customers answer the question, “are we Well-Architected?” The review looks at a number of design principles and best practices across five pillars. The security pillar in particular helped FYI understand the best practices they should be applying.

The Well-Architected framework has a general design principle of “automate to make architectural experimentation easier.” This is further emphasized in the security pillar  with the design principle of “automate security best practices” and in reliability with “automatically recover from failure.” The solution that FYI built leveraged containers to standardize their application deployment process, allowing them to reliably push changes to their code into their environments.

During the review we identified that they could apply a similar pattern to how they deployed their infrastructure by defining their infrastructure as code and deploying into multiple AWS accounts. Infrastructure defined as code allowed FYI to deploy their resources through a build pipeline and multiple AWS account acts as a coarse grained container in which their resources could be isolated.

To start with, FYI created a new root account and started using cross account roles from there. Initially, they just added their existing account as a legacy environment to the organization. They then tied the migration to new accounts as part of their journey towards defining their infrastructure as code. The team at FYI were already very comfortable with their use of AWS; the only new thing they had to learn that was new to them was how to deploy resources into other accounts and how to leverage cross-account roles.

Figure 1. FYI Architecture

As a result of this journey, in addition to improving their security posture, Alan also noted that it really helped to improve the on-boarding experience as the team grew. It was now faster to provision access to new developers because they just had to add them to their central identity store, and they immediately had the same access as others in the team. It also helped them with better mechanisms for enforcing least privilege – developers only received access to roles as appropriate and as changes are needed they can roll them out in a consistent manner.

I also asked McLeod his advice on where other customers should set them selves up to be able to quickly iterate and continue to improve their operations. His advice was to start with a brand-new root account and use that to understand how cross account access works. Once you have that working, you can then start to expand your account structure to achieve your desired end state over time.

To learn more about how you can apply the Well-Architected Framework for improving the security of your start-up, read our post about building a secure AWS foundation on the AWS Security Blog. Don’t forget that we also shared the journey of Tic:Toc earlier this week where you can read about how they created a secure foundation.