Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a customer who is being dogged pretty hard by SOX auditors regarding the deployment practices of our ASP.NET applications. Care is taken to be sure to use appropriate file- and folder-level security and authorization. Only those few with deployment privileges can copy an up to the product server (typically done using secure FTP).
However, the file/folder-level security and the requirement of secure FTP isn't enough for the bean counters. They want system logs of who deployed what when, what version replaced what version (and why), and generally lots of other minutiae designed to keep the business from being Office Spaced (the bean counters apparently want the rounded cents all to themselves).
What are your suggestions for making the auditors happy? We don't mind throwing some dollars at this (in fact, I think we would probably throw big dollars at a good enough solution).
You probably want to look at an automated deployment solution and you are going to need a formal change control process. We use anthill pro. It can track what version and when it was deployed.
To satify sox we had a weekly meeting of what was getting deployed when. It had to be approved by compliance manager and each deployment needed to have a form filled out explaining what, why and how something was being changed. Once the form was filled out a third person had to be involved (not the person requesting or approving, neither of them can have access to the production environment, because of the seperation of duties rule you have to follow) to make the change and the change was based off of what was in the "change document" no outside communication from the person making the request. Once deployed, all people had to sign off that it was done and when.
It shouldn't be too hard to meet the requirements, it might require some changes to your development processes but it's definately possible.
What you need is:
A task tracking system, showing descriptions of work, and approvals
The ability to link documents, as well as packages to this system.
A test system to test your deployments onto.
Finally all deployments must be done via installation packages, and other scripted means.
Any manual changes must be documented and approved too.
Also turn on auditing, run regular security tests, and document almost everything.
All of this is possible with a number of systems, the biggest change is the changes to your internal processes.
You might want to take a look at the auditing features provided by NTFS.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am new to Datapower and have developed/configured a service which is working fine at the moment, I want to take this to production and for that need to create artefacts. Could you help me telling the standard practice and how /what all files I should include ? I heard about manifest file to include but not sure where should I find them.
Also heard about the mkick but not even know what does it do.
Thanks in advance!
As Stefan suggests Deployment policies will likely be of interest for changing settings between your Development and Production environments.
You will want to take a configuration export of your service and use the options to include referenced objects.
Also keep in mind certificates and keys are not included in the export, so if you have any referenced for the configuration, you will need to update those settings on your prod environment before this service can be active.
As answered earlier by Jimb. We can export the service from the DEV, STG environments and import them to Production Environments.
You can use deployment policies, Be sure you first import deployment policy and then the service(Because you have to select the deployment policy when importing the service).
Also You have to export the Keys, Certs and necessary artifacts from the previous environment.
Hope this helps.
Thank You!
Deployment is an integral part of any development architecture. Code deployment is a process of moving the code from your development environment to QA (Quality Assessment) env’t or from conveying env’t to pre-production env’t etc.
In DP the code deployment mean bundling all your code and dependent resources into one env’t and to the target env’t. However, to move from one env’t to the other env’t in practical you may have to face key challenges:
For instance in the process of moving code from dev to QA, both the structure remains the same. But, the detail is different why? Because IP and port no which is available in dev env’t it may not be working if we move along with QA env’t. Therefore, you should change that. The second thing also the backend server details of the dev env’t is also different from the QA env’t. That also needs to change. However, in order to address these challenges, the DP has a set of tools. That tool is the so-called Deployment policy.
Generally, whenever to make deployment and migration we need to keep in mind is :
Identify from and to which application domain is taken place, usually this migration process is taken place from high-level appliance DP to the lower one the process definitely failed.
If the process is taken place the same level appliance say from XI50 to XI52 we need to take care of the code from the lower level firmware to the new one may not be working because the new one may have advanced features.
Migration is working with env’t variables and we need to check that env’t variable. How? Use the deployment policy. However, deployment policy has one weakness is cannot look inside your SSL file and cannot make a change over there. You have to do a deployment policy by yourself.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
It is unclear to me how cloudControl MySQLd addon works.
My understanding of MySQLd is that it is a MySQL server that can/will work with unlimited apps.
But since all addons are only app based, this could also mean that I cannot use the same MySQLd server on multiple apps.
Could anyone please help me understand if one MySQLd instance can be used with multiple apps hosted on cloudControl?
There are two concepts on the cloudControl PaaS. Applications and deployments. An application is basically just grouping developers and deployments together. Each deployment is a distinct running version of the app from a branch matching the deployment name. More details on this can be found in the Apps, Users and Deployments documentation.
All add-ons are always per deployment. We do this because this way we can provide all credentials as part of the runtime environment. This means you don't have to have credentials in version controlled files. Thich is a huge benefit when merging between branches, because you don't risk accidentally talking to e.g. the live database from a dev deployment. Also add-on credentials can change at any time at the add-on providers discretion.
For this reason separation between deployments makes a lot of sense. Usually your dev deployments also don't need the same database power as the production deployment for example. So you can easily use a smaller plan or even a shared database (e.g. MySQLs) for development. You can read more about how to use this feature inside your code in the Add-on documentation.
Also as explained earlier, add-on credentials are always provided as part of the runtime environment. Now credetials can change at any time at the add-on providers discretion. These changes are automatically provided in the environment and the app processes restarted. If you had hard coded the credentials as would be required for the second app, this would mean the app would probably experience downtime.
Last but not least, it's usually very bad practice to connect to the same database from two different code bases in different repositories, which would be the reason to have a second app. This causes all kinds of potential conflicts and dependencies that make code changes and database migrations extremely hard to maintain over time. The recommended way would be to have the data owned by one code base only and provide an API to access that data from the second code base.
All this being said, it is technically possible to connect multiple deployments or even apps to the same add-on (database or anything else) but highly advised against.
If you have a good reason to connect two apps/deployments to the same database I would suggest you manually launch an RDS instance at Amazon (MySQLd is based on RDS) and provide credentials for that through the custom config add-on to both of your apps/deployments.
I hope this answers your question and also explains the reasons.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
We have a custom CRM solution that among several things handles our call-center. That is, each call-center operator gets a queue of people (potential customers) to call based on a number of configurable rules. For example, certain operators only handle certain types of users. Call queues are ordered by call-time taking timezones into account.
EDIT: Operators dial manually. We're currently not interested in automating this.
Now we want to replace this call-center subsystem because it has several bugs, its implementation is very messy and the original developers left years ago.
So we're trying to decide whether to build this ourselves from scratch or integrate another CRM (like SugarCRM) for this specific task only.
But I'm totally ignorant about SugarCRM. Does it provide such a module? Is the SugarCRM API flexible enough to handle different rules to select and order a call queue? We're a .NET shop so we don't want to mess with SugarCRM's code. Or is there any other similar CRM you can recommend for this task? Where do I start?
Thanks in advance
If you are a .NET shop, is there a reason you've not mentioned MS Dynamics CRM ?
While there is a cost associated with it, there is a huge amount of customisation you can do, and if, at some point, you decide to look at telephony, it'd be straightforward to do that too.
I have built CRM systems that integrate with a PBX based dialing system. We had a lot of success with home grown systems.
I would advocate a build from my personal experience for the CRM portion.
What you are asking about, however, is the Dialing side of the system. This can be built as well - the API's for the Dialogic cards lend themselves nicely to .Net implementations. Now that is going to take some work, and most cheap dialers have some decent functionality out of the box to do what we want it to do.
It is when you get to complex functionality that they give up the ghost and by that time you are already so far tied into them that going into a new system is not feasible. I have seen this happen over and over again too.
If you have decent talent on hand, I would advocate writing the dialing system as well if you see yourself having to handle issues more intricate than your basic off-the-shelf dialer can handle.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a small classic asp site and I am concerned that a client may stop paying me. The site is on their server, so I basically want an "off switch" in the event they stop paying me. I couldn't think of a good way to do this as they have a tech person who has access to the server, so any code I write to stop the site would be easily found and changed in the classic asp site (there aren't many pages).
So we had thought of maybe obfuscating the 2 main class pages so that they won't be able to edit the pages easily and we still have code to stop the site functioning. My questions are:
What is the best option for obfuscating classic asp code (if anyone has done this before)?
Is there another option that maybe we're not thinking of?
Thanks for any help you can provide!!
I think your energies are better placed on setting milestones in your project that are tied to payments. This ideally is done in increments so that neither party feels at a disadvantage with regards to the amount of work done / amount of money paid.
Obfuscation is easily removed and decoded, generally.
Remote checking for a security license opens a security hole for the application, and also can be defeated relatively easy.
Putting in code that "self destructs" if some action or code is not removed is also not great practice.
Licensed software is a little bit different in this regard. It sounds like you're building a bespoke system that you will simply hand over to the client at the end. If that's the case, putting in mechanisms to disable that system that only you control is not a great way to build trust. They may be violating trust if they fail to pay, but your disabling of the website actually gives them an additional incentive NOT to pay you, and consider you as a programmer willing to put in a Trojan Horse into the code.
The real problem to solve here is not in code, but in project management. A social not a programming problem.
This is a hard problem, and a great one for StackOverflow. I wish you well in sorting it out.
You're in Australia right? You have a small claims court system? If you've delivered what you were obligated to code for them, you shouldn't have a problem collecting.
I'm pretty sure that programmers have gotten sued or even charged criminally for this sort of thing; the courts see it as "hacking" into a client's site and breaking it over a payment dispute. Be careful.
I believe the best way would be to simply have it call your own server for some critical piece of data. That way you can restrict that service if / when their subscription does not tally with your desired business model.
It does depend a lot on the site, but there will always be something you can return from your own server to keep the site active. Also this does give you the advantage you are not disabling their server but your own if it goes wrong.
hope that helps
There is a tool from Microsoft called Script encoder that encodes a script into garbage, though it's fairly easy to get the original back..
Why not put some of the business logic into a VB6 component? That's valid optimisation and obfuscation in one. They could decompile such a DLL, but it's a lot of hassle.
More importantly, you need to consider who owns the code, regardless of what you do at this point. The link below is a discussion on code ownership in freelance situations (without a contract), and I think that the accepted answer defines the issues rather well: https://stackoverflow.com/questions/111815/freelance-work-with-no-contract-who-owns-the-code
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I was wondering what is the preferred method of licensing a web site?
I distribute precomplied versions of my web sites with editable APSX files, the code behind is complied into separate DLL's for each page.
I have thought of implementing some sort of text injection into each page, similar to what Telerik controls do, when using a trial version. This demo text would disappear if using a licensed version.
One way I would think is to have the web site contact a web service to determine the license status but this would be an issue if the web service is down for any reason.
Thanks
It's absolutely unacceptable to have your controls rely on an external web service to check the license. The only thing you're going to get out of that is pissed off customers and maintenance issues for yourself.
I strongly encourage you to go with the honor system, or a very simple licensing key file (that never expires). You're selling a web site, not video games. Unless you know for a fact that you are losing significant money because of piracy of your product, do not waste your time. Remember the first rule of optimization!
you could build some sort of license controlmechanism into your website. therefore you could use the URL of the site (typically you sell your asp.net app for one or two urls to somebody), and e.g. you could also build some hardware-key-references into your license mechanism, so that a copy of your software is not possible to run on a different machine.
but keep in mind, all restrictions you build in will result in more work for your paying clients, and there is always somebody who want to try to use your software without paying it!