Pro SQL Server 2012 Reporting Services

(sharon) #1

C H A P T E R 11


Securing Reports


If a topic is currently on the minds of administrators more than security, we would be hard-pressed to
name it. We all know that security threats come in many flavors and levels of severity—from the
malicious pop-up Web pages to the invasive worms and viruses that wreak havoc on systems and take
their toll on productivity by wasting time and resources to disgruntled employees to nefarious bots to
skilled system intruders lurking around our data ready to pounce at any moment..
These threats are often anonymous scripts or executables—automatons—that their human creator
has released into the wild. But what about the security violations from real individuals? These are not
just elusive system hackers bent on destruction; they can be the overlooked disgruntled employee who
left the company with a notebook full of passwords and the determination to make a point about the
insecurity of the company’s vital data.
Securing systems takes time and effort and sometimes, unfortunately, has a lower priority than
other important daily tasks. However, if your company is affected by the regulations imposed by HIPAA
and other laws like Sarbanes Oxley (SOX), meeting stringent security standards is a requirement, not just
a recommended practice. Most companies have policies and procedures in place that will meet HIPAA
and SOX compliance. As a roles-based application, SSRS will take advantage of the underlying
authentication and network already at work in your organization. The SSRS security model has three
important components:



  • Data encryption

  • Authentication and user access

  • Report audits


The goal in this chapter is to meet the challenge of effectively setting up and testing each of these
security components in your SSRS deployment. We will show how to do this through our experience
using SSRS to meet security standards.
You can incorporate your SSRS projects in your business in multiple ways. You may have an intranet
site where internal domain users are rendering reports, a .NET application that utilizes the web services
to build and display reports, or even an outward facing SSRS site hidden behind an authentication
portal.


Encrypting Data

When working with confidential data of any kind, the chief concern is that the only people who can see
the data are those who need to see it and who have been specifically granted permission to see it. This is
especially true of Protected Health Information (PHI) data, as defined by HIPAA, which has been a
significant concern of ours as a software development company. Many other types of data also need this

Free download pdf