How to implement SQL Server source control using a shared development model

Having a team of developers working on the same (shared) database can be challenging for many reasons. It is critical to ensure that all changes are properly tracked and that each developer is informed about the status of objects currently used by the rest of the team. When using a shared database, all changes will be applied against the database before they are committed to the repository.

How to implement SQL Server source control using the dedicated development model

Having a SQL Server database under source control is rapidly becoming the norm vs the exception in many software development teams. Using any development model (dedicated or shared), requires the team to establish a workflow and a set of rules. The dedicated model, though, allows a developer to act as an independent part of the process mainly in case the central server/repository is down. In this case, the team can continue to work unhindered. This article will focus on using the dedicated development model for SQL Server source control

How to implement HIPAA regulatory standard for SQL Server – Part 2

In Part 1 of this article it was presented how to set up ApexSQL Audit to implement Administrative safeguards standards of the HIPAA regulatory (the 45 CFR Part 164, Subpart C – Security Standards for the Protection of Electronic Protected Health Information that is developed to accomplish protection of electronic protected health information (EPHI)). In this part, the rest of the Administrative safeguards will be presented, while in the Part 3 we will provide ApexSQL Audit settings which will allow you to fulfill the HIPAA’s Technical safeguards and Policies and procedures and documentation requirements sections

How to implement HIPAA regulatory standard for SQL Server – Part 1

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) sets guidelines mandating the adoption of Federal privacy protections for health information of individuals which gives patients an array of rights with respect to that information. The HIPAA Privacy Rule ensures federal protections for individually identifiable health information and gives patients a range of rights with respect to that information. The Security Rule defines administrative, physical and technical safety measures to ensure the availability, confidentiality and integrity of electronic protected health information.

Before and after auditing in SQL Server

Simply archiving information to audit a database is one thing, but successfully reconstructing an audit history to provide meaningful forensic data is another. It is important to be able to see a full history of user changes, as well as to be able to reverse changes that may have been accidental or malicious.

Ideally, such value added information can be obtained without requiring a prodigious amount of archived data or creating significant performance impact on audited servers.

In this article, we are going to present two different approaches and solutions to before and after auditing.

SQL Server database security auditing

The following auditing implementations are recommended on a database level as part of any database security auditing system:

  1. Schema level auditing:
    • DDL activity
    • Changes made to stored procedures and triggers
    • Changes to privileges, users, and security attributes

How to implement SOX compliance requirements for SQL Server – Part 1

Achieving SOX compliance requirements is the mandatory for all publicly traded companies. But when it comes to most IT teams, SOX compliance can be quite vague and confusing. SOX compliance is not written with technology mandate in mind, but rather a mandate for accounting, legal, and financial reporting.  In the SOX Act there’s no reference can be found to anything specific related to IT. It is often said that SOX was “written by lawyers, for lawyers”