A SQL database source control “label” or “tag” (aka revision tag) (name depends on the particular source control system) represents a snapshot in time of the source control repository and its contents. It can be saved as a reference for the future use. When the database development cycles reach a particular milestone e.g. a new build, a source control label can be created as a checkpoint. The team can continue to work on the database but revert to the source control label at any time.October 27, 2015
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.October 9, 2015
Part 1 of this series shows how ApexSQL Audit should be set up for implementing the Administrative safeguards section of the HIPAA compliance (CFR 45 Part 164, Subpart C – Security Standards for the Protection of Electronic Protected Health Information developed to undertake protection of EPHI). In Part 2, the ApexSQL setup for fulfilling the remaining parts of the Administrative safeguards are discussed.September 22, 2015
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 controlSeptember 17, 2015
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 sectionsSeptember 14, 2015
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.August 31, 2015
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.August 11, 2015
The following auditing implementations are recommended on a database level as part of any database security auditing system:
- Schema level auditing:
- DDL activity
- Changes made to stored procedures and triggers
- Changes to privileges, users, and security attributes
In the first part of the series, we’ve showed how to perform a point in time restore using SQL Server Management Studio and ApexSQL Log. In the second part of the article, we’re going to introduce two more solutions – performing a virtual restore (in time) with ApexSQL Restore, and performing a full point in time restore with ApexSQL Backup.July 31, 2015
The first part of the article provides a common application settings information and described how to meet the COBIT 4.1’s PO2.4 – Integrity management control objective requirements.
This sequel will describe recommended settings of the ApexSQL Audit that helps meeting the COBIT 4.1 control objectives:July 28, 2015