Authorization Matrix
Authorization Matrix
Authorization Matrix
REPORTER: FRANCESS ALLIAH S. BRUNO
• Authentication proves who someone is.
Authorization is what that person is allowed to do.
For example, a typical customer should be able to
read his or her own email but not that of other
people. Certain people should be able to read a
particular database, with a smaller set allowed to
update the data, and only a few administrators
able to make changes to the database schema.
• More useful than setting these policies in paragraph form is to use
an authorization matrix based on roles within the company,
categories of system, and classes of access, such as the one shown
in Table 11.1. The authorization matrix describes the level of access
that a given group of people has on a certain class of machines.
Such a policy should be developed in cooperation with management
and representatives from all parts of the company. Once that is
done, an authorization system should be linked to the authentication
system that implements the policy. The set of identities and
information stored in the authentication and authorization systems is
one of the namespaces at a site. Managing this and other
namespaces is discussed further in Chapter 8.
AUTHORIZATION MATRIX SAVES THE DAY
• Tom entered a site that was having a long debate about
improving the security of certain networks. For the previous 2
months, the site hadn’t been able to reach a decision on which
networks would be able to access which services.
• Up until then, the debate had all been done verbally, never
getting closer to a conclusion. Tom listened to people’s views
and thought he was hearing a lot of overlap, but since the
debate was evolving and positions were changing, he wasn’t
sure where the agreement was and where the disagreements
were.
• In one meeting, Tom said, “Oh, I have a tool that will solve this
problem.” People thought he might be reaching for a baseball
bat. Instead, he opened up a spreadsheet program and drew a
grid.
• He listed the networks in a column on the left and the various
services across the top. He started filling out the individual
boxes where he thought he heard agreement. He then
confirmed with the group that he was capturing things properly.
The group suggested a few more boxes that could be filled in. It
turned out that only a few boxes couldn’t be filled, because they
were yet unresolved.
• Tom suggested that rather than let the very expensive firewall hardware sit in
boxes for another 2 months, the group set it up with the policy in the grid as a
start. The unfinished boxes would be assumed to be “no access” until the grid
was complete.
• During the week it took to install the hardware, management was shown the
grid and given an opportunity to set the policy. These people weren’t very
technical, but the matrix let them make the decision without having to
understand the technology, and they were able to break the tie where the SAs
disagreed. By the time the hardware was ready, the grid was complete. The
engineer installing the firewall only had to make sure that the configuration
accurately reflected the grid. A different SA could then audit the firewall by
comparing the configuration to the grid.
• After 2 months of debate, the entire project was completed in 1 week because
the right tool was used.
11.1.3.6