PhotoGranary/Adobe
Stock
When
cloud
computing
first
became
popular,
it
was
seen
as
a
way
of
reducing
both
friction
and
costs.
It
was
much
faster
and
cheaper
to
spin
up
a
virtual
machine
in
the
cloud
than
to
wait
for
a
physical
server
to
be
approved,
ordered,
delivered
and
set
up.
SEE:
Use
this
access
management
policy
template
from
TechRepublic
Premium
to
build
secure
policies
around
user
access.
Now,
cloud
computing
is
powerful
and
robust
enough
to
run
mission
critical
workloads
—
as
long
as
you
know
how
to
design
applications
to
scale,
configure
cloud
services
to
support
them
and
handle
the
failures
inevitable
in
any
complex
system.
Jump
to:
Avoid
security
flaws
when
building
apps
on
Azure
If
you’re
building
applications
on
Azure,
Microsoft
has
a
Well-Architected
Framework
to
help
you
design
and
run
your
app
for
reliability,
security,
performance
efficiency
and
effective
operations.
It
even
offers
a
quiz
to
help
you
assess
if
you’ve
covered
everything.
There’s
also
a
growing
number
of
tools
and
services
to
help
make
the
applications
you
run
on
Azure
more
reliable
and
secure.
These
tools
range
from
the
Azure
Chaos
Studio
service,
which
helps
you
test
how
your
app
will
cope
with
failure,
to
the
open-source
OneFuzz
project,
which
will
look
for
flaws
in
your
code.
If
you
use
containers,
the
default
configuration
for
.NET
8
Linux
containers
is
now
“rootless,”
and
it
takes
only
one
line
of
code
to
have
your
app
run
as
a
standard
user
rather
than
one
with
root
access.
This
is
to
ensure
attackers
can’t
modify
files
or
install
and
run
their
own
code
if
they
are
able
to
get
into
your
app.
Lock
down
your
apps
In
addition
to
avoiding
security
flaws
when
you
write
your
application,
you
need
to
make
sure
you’re
only
giving
access
to
the
right
people.
You
can
apply
locks
to
any
Azure
resource
or
even
an
entire
Azure
subscription,
making
sure
they
can’t
be
deleted
or
even
modified.
But
because
locks
affect
the
Azure
control
plane
rather
than
the
Azure
data
plane,
a
database
that’s
locked
against
modification
can
still
create,
update
and
delete
data,
so
your
application
will
carry
on
working
correctly.
For
older
applications
that
don’t
have
fine-grained
options
for
managing
how
credentials
are
used,
Azure
Active
Directory
has
a
new
option
to
help
you
secure
those
credentials.
This
way,
an
attacker
can’t
make
changes
that
might
let
them
take
control
of
a
key
enterprise
application
and
get
credentials
to
move
across
your
network
and
attack
other
systems.
Around
70%
of
all
data
breaches
start
with
an
attack
on
web
applications,
so
you
need
to
make
sure
attackers
can’t
use
them
as
a
stepping
stone
to
other
resources.
SEE:
Discover
how
BYOD
and
personal
applications
can
lead
to
data
breaches.
The
new
app
instance
property
lock
feature
covers
credential
signing
with
SAML
and
OpenID
Connect,
which
means
you
can
offer
single
sign-on
that
lets
users
sign
in
with
Azure
AD
and
get
access
to
multiple
applications.
It
also
encrypts
the
tokens
created
using
a
public
key,
so
apps
that
want
to
use
those
tokens
have
to
have
the
correct
private
key
before
they
can
use
those
tokens
for
the
user
who’s
currently
signed
in.
That
makes
it
harder
to
steal
and
replay
tokens
to
get
access.
Modern
applications
will
usually
have
those
kinds
of
protections
available
already.
If
you’re
running
a
legacy
application
that
wasn’t
built
to
protect
these
sign-on
flows,
you
can
use
Azure
AD
to
stop
the
credentials
used
for
signing
tokens,
encrypting
tokens
or
verifying
tokens
from
being
changed.
So
even
if
an
attacker
does
get
access
to
the
application,
they
can’t
block
legitimate
admins
and
take
over.
You
might
also
want
to
look
at
the
permissions
users
have
to
applications
they
install
or
register
on
your
Azure
AD
tenant
and
what
anyone
with
guest
access
will
see.
Check
out
your
network
If
your
cloud
app
has
a
problem,
sometimes
it’s
a
network
problem,
and
sometimes
it’s
how
you’ve
configured
the
network
options.
Azure
Virtual
Network
Manager
is
a
new
tool
for
grouping
network
resources,
configuring
the
connectivity
and
security
for
those
resources
and
deploying
those
configurations
to
the
right
network
groups
automatically.
At
the
same
time
it
allows
for
exceptions
for
resources
that
need
something
like
inbound
Secure
Shell
traffic,
which
you’d
normally
block.
You
can
use
this
to
create
common
network
topologies
like
a
hub
and
spoke
that
connects
multiple
virtual
networks
to
the
hub
virtual
network
that
contains
your
Azure
Firewall
or
ExpressRoute
connection.
The
Azure
Virtual
Network
Manager
also
automatically
adds
new
virtual
networks
that
need
to
connect
to
that
resource
or
(soon)
a
mesh
that
lets
your
virtual
networks
communicate
with
each
other.
Azure
Network
Watcher
already
has
a
mix
of
tools
to
help
you
monitor
your
network
and
track
down
problems
that
might
affect
your
VMs
or
virtual
network.
It
can
draw
a
live
topology
map
that
covers
multiple
Azure
subscriptions,
regions
and
resource
groups
as
well
as
monitor
connectivity,
packet
loss,
and
latency
for
VMs
in
the
cloud
and
on
your
own
infrastructure.
But,
having
multiple
tools
for
finding
specific
problems
means
you
have
to
know
what
you’re
looking
for.
The
new
connection
troubleshooting
tool
in
Network
Watcher
runs
those
tools
and
reports
back
on
network
hops,
latency,
memory
and
CPU
utilization
as
well
as
whether
it
could
make
a
connection
and,
if
not,
whether
that’s
because
of
DNS,
network
routing
rules,
network
security
rules
or
the
firewall
configuration.
You
can
also
use
Network
Watcher
to
run
other
tools
like
a
packet
capture
session
or
Azure
Traffic
Analytics,
which
helps
you
visualize
the
network
flow
in
your
application.
Azure
Traffic
Analytics
can
even
map
the
topology
of
the
network,
so
you
can
see
which
resources
are
in
which
subnet
and
which
virtual
network
each
subnet
is
part
of.
If
you
use
Network
Watcher’s
network
security
groups,
you
can
use
Traffic
Analytics
to
make
sense
of
the
flow
logs,
which
track
ingress
and
egress
traffic
to
look
for
traffic
hotspots
or
just
see
where
in
the
world
your
network
traffic
is
coming
from
and
if
that
matches
what
you
expect.
You
can
also
use
this
to
check
that
you’re
using
private
links
rather
than
public
IP
connections
to
reach
sensitive
resources
like
Azure
Key
Vault
—
a
mistake
that’s
surprisingly
easy
to
make
if
you
use
a
public
DNS
server
rather
than
the
Azure
DNS
server.
Getting
the
network
configuration
right
is
an
important
part
of
keeping
your
apps
secure
in
the
cloud.
About Author
