IAM: Best practices

Posted by on Dec 2, 2013 in AWS, Cloud

The more I play with (and love) AWS as a platform, the more the significance and power of IAM becomes. This post outlines IAM and how it should be used effectively within Amazon’s cloud environment. What is IAM? IAM, or Identity and Access Management is the primary means of securing users, groups and permissions. IAM is complimentary to services such as security groups and Access Control Lists (which govern Instance and Subnet security respectively). Best Practices Amazon strongly recommends (and I completely agree) that the root/master account should not be used for anything other than administering the Amazon account and creating administrative accounts. Thereafter you should be logged in as a named user (if the master account is a company account) with the minimum required privileges to do your job. With great power comes great responsibility, and its quite easy with AWS to inadvertently terminate the wrong instance (thus bringing a production server offline) or incorrectly route traffic to the wrong subnet for example. Therefore you should take the time to scope out what level of access each user requires, what functions they need to be able to perform to do their job and then match this up with the IAM policy generation tools. Amazon have done a fantastic job of giving granular access to the services and its contained functions – to the point where you can permit a user to reboot a server but not terminate it, or retrieve content from S3 but not upload (or vice-versa).Thus, as part of your getting started with IAM you should navigate to the IAM section of AWS and set up user(s) pertaining to the role they need to perform Another best practice is that if a user does not need API access, do not generate the key(s) necessary to enable it. Sure, they’re inherently obscure but why risk it? Oddly enough Amazon defaults the ‘Generate and access key for each user’ checkbox to ticked, so unless you explicitly disable this they will be created. Conversely, if a user ONLY needs API access and doesn’t need to access the console, then do not generate an IAM password that would allow them to log in to the AWS console. By default new accounts do not have a login password, and thus you control who has access to the AWS console. As with all security in IT, the least required privileges, the better! IAM roles are a relatively new addition to the IAM offering. Roles allow you to assign effective permissions to a particular role as you would a user or group, but assign this to an EC2 instance. Why would you do this? Well, prior to roles, developers would have to embed API keys & secrets in their code or user-data (or use some other mechanism for getting credentials onto an instance) in order to permit it to access another AWS service...

Read More »

Enabling HTML files to be processed by the asp.net pipeline

Posted by on Oct 10, 2013 in Asp.net

A quick how-to here. I recently needed to process all HTML files through the ASP.Net pipeline so I could take advantage of its security features. The obvious solution to this would be to run all modules through the pipeline by adding the following to your web.config: C# <modules runAllManagedModulesForAllRequests="true" /> 1 <modules runAllManagedModulesForAllRequests="true" /> However, there would be a performance hit then on other static file types such as CSS, JavaScript and images. The correct way to achieve this is through the following web.config changes: C# <system.web> <compilation debug="true" targetFramework="4.0"> <buildProviders> <add extension =".html" type="System.Web.Compilation.PageBuildProvider"/> <add extension =".htm" type="System.Web.Compilation.PageBuildProvider"/> </buildProviders> </compilation> </system.web> 12345678 <system.web>  <compilation debug="true" targetFramework="4.0">    <buildProviders>      <add extension =".html" type="System.Web.Compilation.PageBuildProvider"/>      <add extension =".htm" type="System.Web.Compilation.PageBuildProvider"/>    </buildProviders>  </compilation></system.web> This tells the runtime that the .htm and .html extensions should be picked up and processed by the PageBuildProvider via System.Web.dll Then, to ensure this is correctly processed by IIS or IISExpress (or any other asp.net capable web server), add the following section, also to your web.config file: C# <system.webServer> <handlers> <add name="HTML" path="*.html" verb="GET, HEAD, POST, DEBUG" type="System.Web.UI.PageHandlerFactory" resourceType="Unspecified" requireAccess="Script"/> <add name="HTM" path="*.htm" verb="GET, HEAD, POST, DEBUG" type="System.Web.UI.PageHandlerFactory" resourceType="Unspecified" requireAccess="Script"/> </handlers> </system.webServer> 12345678 <system.webServer>        <handlers>            <add name="HTML" path="*.html" verb="GET, HEAD, POST, DEBUG"                 type="System.Web.UI.PageHandlerFactory" resourceType="Unspecified" requireAccess="Script"/>            <add name="HTM" path="*.htm" verb="GET, HEAD, POST, DEBUG"                 type="System.Web.UI.PageHandlerFactory" resourceType="Unspecified" requireAccess="Script"/>        </handlers>    </system.webServer> The above handlers instruct the runtime to run all requests for GET, POST, HEAD or DEBUG verbs through the PageHandlerFactory. With this in place you can then handle HTML files through the pipeline, which is ideal for scenarios such as integrating the asp.net security architecture into static sites containing HTML files rather than a WebForms or MVC...

Read More »