The Black Book of Identity Access Mgmt
This form does not yet contain any fields.

    Is Sharepoint a risky ride?

    Like most kids, my own kids like to ride their bikes. They take their bikes around the neighborhood, to other kids' houses, to the park, just out for a spin. Those bikes are extremely useful. They save time, wear on the shoes, and of course they're fun. They get you from one place to another, just like my car gets me from the house to the store and back. So why wouldn't I just say to the kids, "Hey, the bikes serve essentially the same purpose as the car. So here's some money. Ride your bikes to the store, buy a few bags of groceries, and bring them all home. Don't forget to grab a couple of gallons of milk, too."

                That's stupid, you might say. A bike doesn't have a trunk, you observe. You're asking it to do too much, you'd add. On top of that, the bike isn't safe in all that traffic. Am I not asking too much of a bike? You betcha. The bike has its purpose, but you can't ask too much of it, or its operator. And yet this is what I see happening all the time with Microsoft Office Sharepoint Server.

                Sharepoint is a dandy collaboration tool, allowing individual corporate departments to quickly and easily put up sites for sharing content on a discrete basis. And there’s the rub: quickly and easily. Way too many organizations have little to nothing in the way of policies on who can create a site. There’s no governance. No best practices. It’s just a Microsoft tool, right? Yep, one that’s commonly used for publishing corporate content. This is why you end up with hundreds or even thousands of sites within a single enterprise, many with their own content management policies, if you can call them that, and if they even exist.

                Most companies don’t even properly provision MOSS users so as to control entitlements. Site creators are running their own show in way too many instances. Here, let me toss you into this group, so you can access my site. Pages, lists, files. There is often no standard for the metadata used for filtering searches. Which means the further down the food chain you go, the uglier it gets. If there are no best practices on who can make a site, there’s less of a chance you’ve got adequate rules on who can view that site.

                Site proliferation. Content proliferation (“We’ve been meaning to put all those files out where everbody on the team can find them.”). Lack of audit capabilities. No standards for governance.

                There are tools available within Sharepoint, but their use is not enforced, and there truly are no standards. And even if you use them, they’ll be used for Sharepoint alone. For the sake of efficiency and governance, wouldn’t you be better off integrating your corporate best practices, the same ones you (hopefully) use for the rest of the enterprise, for your Sharepoint environment? Provisioning, access management, and reporting will provide the biggest value and consistency when applied across the board. In "Lord of the Flies," all the kids on their little island, with no rules, start spearing each other. The civilizing influence of, well, civilization provides a standard of behavior that serves us well. When everybody does their own thing, you get innovation, which is great until that innovation creates holes. Get everybody on board with standards and best practices, so they can innovate safely.

                Keep letting your kids ride that bike, sure. Just make them wear a helmet, teach them the right way to ride, and keep an eye on where they’re going.



    The Cloud's a scary place to hang out

                 I keep seeing articles on cloud computing, and some of them give me a chuckle. It's like a cool new toy, only it's got very sharp edges. You want to play with it, but you also want to keep all your fingers. And in a time when hacks and thefts and privacy issues are all over the news, with HIPAA and SOX and PCI standing over us with big sticks, we want to be told that it's okay to bounce back and forth between apps we host and apps that are hosted FOR us.

                Cloud computing is one of those things like the web itself, where, at the outset, everybody's admiring the water but relatively few people are diving in. I remember sitting on a rental car bus in Detroit in the late nineties with an executive from a computer manufacturer, listening to him tell me that web sites were "cute" but that nobody took them seriously, and you certainly wouldn't do business on one of them. Right now, the Cloud has the same allure, and creates the same kinds of ambiguity. You want to take advantage of software as a service, and with somebody else doing all the chores. Instead of sweating all the nasty details of how things work, you instead interact with a transactional framework, a service. You give me data, I store it. You give me more data, I process it and provide the results. And don’t forget about the usual stuff you would sweat if you were hosting it yourself: on-boarding, off-boarding, and access control. Are those available as services as well? If not, can you manage identity and access remotely?

                You pay for your use (out of operating expenses, because you have no capital expense), and if the cloud vendor has a hardware or software issue, it's on them, and you don't care, as long as they guarantee uptime and security.

                But there's the scary part, right? Data, transactions, names, account numbers, intellectual property, they're moving in and out of your security perimeter (assuming your compliance auditors allow you to store certain kinds of data outside your own firewall). If your cloud vendor fouls up (as happened with Google docs and others) and lets your most sensitive stuff leak out, it's their boo-boo, but your liability. This means that the same kind of security audit you might perform on your own infrastructure is something you need to have on paper with your vendor.

                Some parties, like certain EU countries, have policies on where your data may reside, and/or who may have "ownership" of it. This means that for some of your data, you aren't allowed to let it outside your perimeter. Remember that perimeter you should envision when performing a security audit? The one all your most precious assets need to stay behind?

                When you head into the cloud, you don’t just hand over control. You need a policy on cloud security, with data security, privacy, and access control provisions, just as if you were doing it yourself.

                When it comes to a cloud host, you don't just want that guarantee of uptime. You need a guarantee of safety and compliance, as well as interoperability (SSO/federation, dta transfers) with your internal apps. If you can get all that, and you can if you look hard and ask all the right questions, then everything's dandy. If not, then keep shopping, or start pricing servers.

    Page 1 ... 21 22 23 24 25