Raphaël: Welcome back to our
series on EC's methodology.

Last time we talked
about containers today.

We're talking about security.

You are always going to have security
concerns, but you can do your best to

address obvious ones early and keep track
of them as you work on your project.

There are always going to be attack
vectors that you, or the tools that

you depend on haven't considered.

While you cannot control
what you don't know.

You can take steps to avoid surprises.

As you're developing your app, always
make sure to keep access locked

down by default, whether that's
data or servers or anything else.

From there you'll incrementally open
it up to people who require access.

If you do the reverse, have an open
system and incrementally lock it down,

you're almost guaranteed to leak some
data at some point somewhere somehow.

It's going to happen.

As you're configuring your infrastructure,
you'll also want to make sure to think

about locking down traffic between
services and with the public internet.

In AWS in its most basic form that might
mean using things like security groups.

On DigitalOcean that might mean
using their cloud firewalls service.

In either case we like to use tools
like CloudFlare to mitigate against

things like distributed denial of
service attacks and other things.

You'll also want to make sure that you
keep access to servers locked down.

In AWS that might mean making
sure that the people who have

access to the keys to SSH into a
server is as limited as possible.

You will also want to make sure that
you're using, IAM policies to restrict

access to services and resources.

Always keep access as limited as possible.

It might seem basic, but another
thing that's worth mentioning

is do not password share.

We have seen people do this in
the past, and it's always a mess.

Sometimes you have a team
member who leaves and you

shared the password with them.

Now everyone needs to update
the password for their own use.

And it's just not efficient.

It's not safe.

Make sure that if you're using a
service that requires multiple people

to interact with one resource that you
invite them through their team features

so that you can easily revoke access to
specific people when they leave the team.

We understand that that usually
means an increased cost, but

believe me, it's worth it.

If you found this helpful, and you want
to learn more about how we build apps

or more generally how app development
works, we've put together a free PDF

that explains our process and some other
stuff that you might want to learn about.

We also want to know what has your
experience been with security?

What things would you recommend?

Follow us.

If you want to keep up with this
series, we have a lot more to share,

and we're always updating our processes.

As we learn from ourselves,
our community and our partners.

If you think we could work together,
we'd love to partner with you and

help you out with your next project.

Thanks and see you next time.