Securing SQL Server with Digital signature certificate:
As we have demonstrated in one of our recent articles dedicated to SQL Server 2012 Integration Services published on this forum, there are several different ways of restricting access to SSIS packages and confidential information they contain. However, preventing unauthorized users from running or viewing the content of your code is not the only security measure that you should take into consideration. With proliferation of Internet-based technologies and globalization of the software marketplace, it is also important to provide assurances to those who are intended customers that packages they obtained come from a legitimate source and have not been altered without consent and oversight of their original designers. This objective can be accomplished by applying concepts from the field of cryptography to procedures dealing with SSIS package creation and maintenance. In our presentation we will briefly explain these concepts and describe how they can be implemented in SQL Server 2012 Integration Services.
In the most basic terms, the solution that provides sufficient assurances in such scenarios relies on digital signatures. Just like their traditional, hand-written counterparts, their primary purpose is to uniquely identify one entity (such as a company developing SSIS packages) to another (such as a customer who decided to acquire these packages to automate its internal business processes). Their underlying technology is digital cryptography, which, in this particular case involves the use of a pair of asymmetric keys. One key (designated as private) remains in the exclusive possession of its owner (the software company in our example), while the other (referred to as public) is readily available to anyone who requests it (such as a prospective customer).
Signing involves calculating a unique hash (using a specially crafted algorithm) based on some content that will be available to both parties (private and public), encrypting it with a private key, and attaching the result to the original content. Anyone with access to the public key can retrieve the hash and compare it to a result of its own calculations based on the same algorithm. Any discrepancies indicate that the original data has been modified. In addition, since private and public keys are inherently linked, the authenticity of the content creator (and signer) can be also easily confirmed.
Effectiveness of the protection provided by asymmetric keys depends on the credibility of their issuer. More specifically, those utilizing public keys need to trust that the corresponding private keys are in the possession of their rightful owner. Obviously, this raises a question about the basis of such trust, which is where digital certificates come into play. Certificates are digitally signed statements issued by entities known as Certificate Authorities (or simply CAs) following a request from a prospective signer (and a private key owner). Commercial CAs are well-known and established companies, whose reputability is contingent on their diligence in verifying the credentials of their clients as well as evaluating authenticity and accuracy of their requests.
Once these actions are successfully completed, a CA packages a public key in the form of a certificate, which provides information identifying both the owner (i.e. the original requestor) and the issuer (i.e. the CA), its purpose (such as encryption, secure Web communication, digital signing, smart card authentication, etc.), as well as its expiration date. The certificate content is digitally signed with a private key that belongs to the CA. At this point, the certificate can be made available to anyone who wants to be able to verify the identity of the private key owner (and, in the case of code signing, also the authenticity of the digitally signed content). This process works as intended providing that those relying on the certificate trust the issuing CA (which is typically accomplished by adding its certificate in the Trusted Root Certification Authorities store on their computers).
Read full story here
As we have demonstrated in one of our recent articles dedicated to SQL Server 2012 Integration Services published on this forum, there are several different ways of restricting access to SSIS packages and confidential information they contain. However, preventing unauthorized users from running or viewing the content of your code is not the only security measure that you should take into consideration. With proliferation of Internet-based technologies and globalization of the software marketplace, it is also important to provide assurances to those who are intended customers that packages they obtained come from a legitimate source and have not been altered without consent and oversight of their original designers. This objective can be accomplished by applying concepts from the field of cryptography to procedures dealing with SSIS package creation and maintenance. In our presentation we will briefly explain these concepts and describe how they can be implemented in SQL Server 2012 Integration Services.
In the most basic terms, the solution that provides sufficient assurances in such scenarios relies on digital signatures. Just like their traditional, hand-written counterparts, their primary purpose is to uniquely identify one entity (such as a company developing SSIS packages) to another (such as a customer who decided to acquire these packages to automate its internal business processes). Their underlying technology is digital cryptography, which, in this particular case involves the use of a pair of asymmetric keys. One key (designated as private) remains in the exclusive possession of its owner (the software company in our example), while the other (referred to as public) is readily available to anyone who requests it (such as a prospective customer).
Signing involves calculating a unique hash (using a specially crafted algorithm) based on some content that will be available to both parties (private and public), encrypting it with a private key, and attaching the result to the original content. Anyone with access to the public key can retrieve the hash and compare it to a result of its own calculations based on the same algorithm. Any discrepancies indicate that the original data has been modified. In addition, since private and public keys are inherently linked, the authenticity of the content creator (and signer) can be also easily confirmed.
Effectiveness of the protection provided by asymmetric keys depends on the credibility of their issuer. More specifically, those utilizing public keys need to trust that the corresponding private keys are in the possession of their rightful owner. Obviously, this raises a question about the basis of such trust, which is where digital certificates come into play. Certificates are digitally signed statements issued by entities known as Certificate Authorities (or simply CAs) following a request from a prospective signer (and a private key owner). Commercial CAs are well-known and established companies, whose reputability is contingent on their diligence in verifying the credentials of their clients as well as evaluating authenticity and accuracy of their requests.
Once these actions are successfully completed, a CA packages a public key in the form of a certificate, which provides information identifying both the owner (i.e. the original requestor) and the issuer (i.e. the CA), its purpose (such as encryption, secure Web communication, digital signing, smart card authentication, etc.), as well as its expiration date. The certificate content is digitally signed with a private key that belongs to the CA. At this point, the certificate can be made available to anyone who wants to be able to verify the identity of the private key owner (and, in the case of code signing, also the authenticity of the digitally signed content). This process works as intended providing that those relying on the certificate trust the issuing CA (which is typically accomplished by adding its certificate in the Trusted Root Certification Authorities store on their computers).
Read full story here
1 Comments
digital signature Adobe Reader
ReplyDeleteYes, it is absolutly true that all your previous articles about the ways of restricting access to SSIS packages and confidential information they contain were great! I enjoyed reading all of them
Thank you for your valuable comment.