Beyond Corp – Google’s approach to enterprise security

What is Beyond Corp?

Beyond corp is a concept which was developed and is used by Google and is by now adopted by some other companies. The idea behind it was to get away from the intranet and its perimeter defense, where, if you breach the perimeter you can access much of the enterprise data. With Beyond Corp, your enterprise applications are not hidden behind a perimeter defense but are instead deployed to the internet, only accessible via a centralized access proxy. With the deployment of the enterprise applications to the internet, Google establishes a zero trust policy – anyone no matter from which IP tries to access a enterprise application has to have sufficient rights, determined through device and user data.

The trigger for this to happen was the “Operation Aurora” in 2009, an advanced persistent threat (APT) supposedly originating from China, where data from Google and around 35 other companies in the USA was stolen. Since you wont detect an APT through monitoring, because the many single steps in themselves are uncritical and hard to relate if the attackers take their time (talking about several weeks), but are easy to achieve once you entered the intranet successfully,  Google decided to start the Beyond Corp project to find a more secure architecture for their enterprise.

Continue reading

Testing a MongoDB with NodeJS, Mocha and Mongoose

Related articles: ►Take Me Home – Project Overview  ►CI/CD infrastructure: Choosing and setting up a server with Jenkins as Docker image Android SDK and emulator in Docker for testing  ►Automated Unit- and GUI-Testing for Android in Jenkins 


Setting up the testing environment and workflow

Setup:

  • Jenkins CI Docker Container
  • MongoDB Docker Container
  • Production-MongoDB on mlab.com
  • NodeJS Web-Application, hosted on heroku.com

Regarding our database tests we wanted to achieve two things: first of all, we wanted to test any functions of our web application using mongoose which change persistent data. Secondly, we needed database tests to test if eventual model-changes are compatible with our data in the production database.
In relational database management systems one defines constraints in the database, which are tested by the database tests. Since we are using MongoDB though, we don’t really have any constraint in the database. Instead we can define any needed constraints with mongoose right in the application. Therefore, cloning the production database for testing is only required when migrating data (or when having constraints defined) but non-essential for the consistency of the as-is backend.
So alternatively when testing a MongoDB we could also use a shell-script or a “before”-function, that gets called once before starting the tests, to define our database testing environment, like creating the same collections we have in the production database and put in test data for our test cases.
Continue reading