Showing posts with label practices. Show all posts
Showing posts with label practices. Show all posts

Saturday, February 25, 2012

designing for encryption ...

In light of SARBOX, ChoicePoint security breaches, identity theft etc, what
are some best practices regarding encryption and security of this type of
info? I know this is a pretty broad question, so links to other sites are
great, but I'd like to hear some personal experiences and opinions.
The reason is I have identified what I consider potential security problems
in our systems. I need to get get a sense of how critical these particular
issues are (I tend to take the position that hyper vigilence is best so for
me everything is critical) and get them in front of management to hopefully
get some action. But I always think it's best to have at least a proposal
for a solution when presenting a problem.
Anyway, any feedback is most appreciated.
Bob Castleman
DBA PoseurHere is a little something from a mind far greater than mine...
http://vyaskn.tripod.com/sql_server...t_practices.htm
Peter
"The length of this document defends it well against the risk of its being
read."
Winston Churchill
"Bob Castleman" wrote:

> In light of SARBOX, ChoicePoint security breaches, identity theft etc, wha
t
> are some best practices regarding encryption and security of this type of
> info? I know this is a pretty broad question, so links to other sites are
> great, but I'd like to hear some personal experiences and opinions.
> The reason is I have identified what I consider potential security problem
s
> in our systems. I need to get get a sense of how critical these particular
> issues are (I tend to take the position that hyper vigilence is best so fo
r
> me everything is critical) and get them in front of management to hopefull
y
> get some action. But I always think it's best to have at least a proposal
> for a solution when presenting a problem.
> Anyway, any feedback is most appreciated.
> Bob Castleman
> DBA Poseur
>
>|||SARBOX is not an area I'm expert in but one thing I know about security
is that it isn't the same as encryption. Encryption is just one tool
for security. So "designing for security" is something different from
"designing for encryption" and I would advise you to focus on the
former rather than the latter. As I understand it SARBOX does NOT
mandate that any data be encrypted it just requires "adequate" internal
controls.
David Portas
SQL Server MVP
--|||I believe that Sarbanes Oxley suggests or recommends all "Sensitive" data be
encrypted in a data store.
SSNs
Account Numbers
Visa Numbers
etc etc etc
I could be wrong (I'm not a SOX Audit expert either)
Greg Jackson
PDX, Oregon|||Not a lawyer or security expert but California law, SB 1386
(http://info.sen.ca.gov/pub/01-02/bi...86_bill_2002092
6_chaptered.html) mentions unencrypted data. It seems that if someone where
to breach your database and personal information was encrypted you would not
need to disclose the breach.
See [url]http://informationw.com/story/showArticle.jhtml?articleID=10700814[/url]
for an overview...
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23Jf3G$8LFHA.576@.TK2MSFTNGP15.phx.gbl...
> I believe that Sarbanes Oxley suggests or recommends all "Sensitive" data
be
> encrypted in a data store.
> SSNs
> Account Numbers
> Visa Numbers
> etc etc etc
> I could be wrong (I'm not a SOX Audit expert either)
> Greg Jackson
> PDX, Oregon
>

Designin and Processing Cubes

Does anyone have any best practices for processing cubes on a prod environment? If we have 1 server which we have the production cube on, what is the best way to get the changes into the production cube. I tried a backup and restore of the AS DB with no success. Should I just create the database on a dev server and keep prod and dev separate? Any assistance would HELP BIG TIME!!!

The ultimately the question is: what configuraion you can afford to have. The better practice many Analysis Services users have found is to have 2 servers: Staging and Production. You were to maintatain your production server for users to query and during late night you'd use Sychronization feature of Analysis Services to push a new state from the Staging server. On the Staging server you process updates into your dimensions and partitions, you do your backups and test whether the data is correct, you test your security in short you make sure you get your cubes ready before user can see them.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights.

Tuesday, February 14, 2012

design best practices on series number

Hi,

I need to design a table header for inventory transactions with the specifications as follows:

1. System-generated series numbers (integer)

2. Series numbers must be unique by branch by transaction type. Thus if I have following:

Branches: Br1, Br2

Transaction Type: SRS (Stock Receipt from Supplier), SRB(.. from Branch)

The series number must be implemented in such a way that,

Br1 SRS 0000000001

Br1 SRB 0000000001

Br2 SRS 0000000001

Br2 SRB 0000000001

Then, in every INSERT, series number should be incremented by 1, grouped by branch by transaction type. That is, after INSERT with Br1/SRB the figure may now look like,

Br1 SRS 0000000001

Br1 SRB 0000000002

How do I design my table in order to achieve this? Note that this table header will have a detail (master/detail) referenced by foreign key.

Thanks in advance.

What I have come up so far are the following:

1. Create an identity field which will be the designated PK for the table header.

2. Branch, Trx_Type, SeriesNum will be a compounded index with a unique constraint.

3. In the branch office, there will be a shared text file containing the last series number for the branch so that, upon saving the transaction (setup is real-time online), the system will get the last series number from the file then increment by 1 and use it as the series number for the transaction. Upon completion, the system will update the file with the new last series number.

I need your comments on this, and if you have a better solution, pls let me know.