Although the time frame has passed I would be amiss if I didn’t continue on my journey of joining in these block parties; with that said I’m going to write what I “would” have contributed. This month’s topic is intriguing in that it can cover a wide array of discussion – Passwords.
When I think of passwords I think of etiquette. I cannot tell you how many times I have been on calls, meetings, emails, and the list could go on of scenarios that relate to passwords where users just don’t think or take into consideration the impact of their actions. To me the last four words are the key, “impact of their (our) actions“.
- Conference Calls – how many times have you been on a production call with numerous individuals and hear someone say, “Okay here is the user name and password?” If you have then you are not the only one. Credentials should be kept out of the hands of unnecessary individuals.
- Open Text Passwords in tables – check into encrypting those; protect yourself before you realize breaches have occurred and you are left holding the bag.
- Email – transmitting password information via email; not a big fan of. This kind of relates back to the conference call section; who all is on the email? Are you sending it to Project Managers and the like? Probably not the best choice to make.
- Backups sent offsite – do you have any backups going off site? Is any pertinent credentials contained in the dB and if so are your backups being encrypted before shipping them off?
- Length – Look at the length of the passwords you are creating; how strong is the password you are making?
- Sharing – don’t do it; simple enough.
All the above reflects, what I deem, good etiquette. That barely scratches the surface. You have to take into consideration many other factors one of them being a policy. Small, big, medium – whatever kind of shop you are in define out what the best practice is for your shop and then adhere to it. A good reference could be found on Technet Best Practices
Lastly, if you feel as though a password has been compromised be proactive and take the necessary steps to change it. Don’t wait for something to happen; you be the game changer.
Get your defense model in place and let the good times roll.
Being a DBA and working with various teams, I have become accustomed to deploying SSIS packages. I’ll even go back further and, dare I say, DTS packages (I hope everyone did not just fall on the floor while reading that). Now-a-days this Database Professional does more deploying packages than developing them; with that said I was pleased when 2012 came along.
When the newer version of SSIS was released it offered several new features, one of those features was building a deployment model thus producing an ISPAC file. I remember first coming across this and thinking, “Wow, this is all packaged up”. While I won’t go into the specifics of how to build the deployment I will show you the step by step process of deploying the ISPAC file.
Locate the ISPAC file. Once located double click on the ISPAC file to gain entry into the deployment wizard.
What kind of Integration Services project do you want to deploy? Since we are dealing with an ISPAC file on our local directory we will select the source path we found from Step 1. Simply browse to the path location and click ok.
So you have your ISPAC file selected and you want to deploy it; where does it go? You have the capability to supply any Server Name for rapid deployment. The path reflects the SSISDB catalog which is required for SSIS 2012 packages to be deployed. If your SSIS package is already on the server you can simply choose to overwrite the existing file at deployment time.
After you select the destination path; it is then time for review. The review section will provide you with a great overview of the Source path of the file being deployed and the destination location.
Once verified and the deployment button is hit we are off to the races. The ability to have quick insight into the deployment and the methodology to save the report for future use is stellar. If your deployment did fail; at this step you would be able to dive into the error in the result pain on the right hand side.
Seems simple enough? The deployment method in SSIS 2012 has proved beneficial for myself and is a welcomed aspect. Earlier this year I completed a post on the utilization of PowerShell and how to deploy 2012 SSIS packages and that can be found here.
I tell you what; check out what my other colleagues have to say on something they learned recently around SSIS:
- Julie Koesmarno: Currently on sabbatical
- Jeffrey Verheul: SSIS: Zipping files with WinRAR
- Mickey Stuewe: SQL Server Data Transferred to a SQLite Database Using SSIS
On a SQL Collaboration Quest
Four SQL professionals gathered from the four corners of the world to share their SQL knowledge with each other and with their readers: Mickey Stuewe from California, USA, Chris Yates from Kentucky, USA, Julie Koesmarno from Canberra, Australia, and Jeffrey Verheul from Rotterdam, The Netherlands. They invite you to join them on their quest as they ask each other questions and seek out the answers in this collaborative blog series. Along the way, they will also include other SQL professionals to join in the collaboration.