1．はじめに

SHIFTのナショナルセキュリティ事業部所属の松尾です。

昨今、セキュリティ分野の業務に携わっている方であればNIST SP800シリーズというフレーズを聞くことがあると思いますが、当シリーズのうちNIST SP800-171をAWS環境に導入すると何が実現できるのかを本記事にて解説いたします。

2．NIST SP800-171とは何か

NIST SP800-171（以下、「171」）とは『CUI（非機密の中でも重要な情報）』を保護するためのセキュリティ基準のガイドラインです。171の対でよく出てくるNIST SP800-53（以下、「53」）は、管理策集であり、『CUI（非機密の中でも重要な情報）』から『CI（機密情報）』までカバーしています。

なお、ここで『CUI（非機密の中でも重要な情報）』と記載すると、大して重要な情報ではないように感じますが、ここでの「機密」は連邦政府にとっての機密を示しているため、民間企業におけるそれとはかなり隔たりがあります。具体的には、『CUI（非機密の中でも重要な情報）』を一定量収集すると、『CI（機密情報）』を推測できるという点に着目する必要があります。米国はDoDコンポーネント（DoDを中心とするDoD構成組織）と取引をするためには、この171への準拠を取引企業に求めています。

171ではセキュリティ基準を満たすために必要な要求事項が示されるだけで具体的なセキュリティ管理策が記載されていないケースがほとんどであり、その管理策は53に記載されています。そこで171の要求事項を満たすようにセキュリティ実装するためには、各要求事項に対応した管理策を53側で参照する必要があります。

171は業務委託先（関連会社）との調達から販売・供給までの一連のサプライチェーンに存在するリスクからCUI（非機密の中でも重要な情報）を保護するためのセキュリティ基準のガイドライン、簡単に表現しますと、

サプライチェーンリスクマネジメント（SCRM）を実施するためのセキュリティ基準のガイドライン

となります。 SCRMについては、下記に詳しく書かれております。

【出典】"サプライチェーンリスク管理とは（SOMPO CYBER SECURITY社）"

3．NIST SP800-171を導入したAWS環境

2022年に弊社はAWS社のご協力のもと、国内初で171を適用したAWS環境を構築しました。これは、サプライチェーンリスクに対応したAWS環境を構築したことを意味しています。

当環境の利用例として業務委託元と一連の委託先間での、サプライチェーンリスクに対応したファイル共有環境が挙げられます。

4．AWS環境（NIST SP800-171準拠）のリファクタリングの余地

当環境は、次図のとおりAWS CloudFormationで半構造化のYAMLベースでリソース管理されていることから、通称YAML職人と呼ばれる人でないと取り扱いが困難な状態にあり、もったいないなとは思っています。

理想的ではありますが、これをAWS CDKによりTypeScript等の馴染みのあるプログラム言語にリファクタリングすれば保守性の向上につながると考えています。

以下は、Amazon EC2作成を例とした、AWS CloudFormation（YAML）とAWS CDK（TypeScript）の各サンプルコード（イメージ）になります。個人的にYAMLはインフラ職人、TypeScriptはアプリケーション職人がそれぞれ慣れているイメージがあります。

＜例＞Amazon EC2の作成（AWS CloudFormation/YAML）

AWSTemplateFormatVersion: '2010-09-09'
Description: AWS CloudFormation Template to create an EC2 instance

Resources:
  MyEC2Instance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t2.micro
      ImageId: ami-XXXXXXXXXX
      KeyName: my-key-pair
      SecurityGroupIds:
      SubnetId: subnet-12345678

  MySecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Enable SSH access
      VpcId: vpc-12345678
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: '22'
          ToPort: '22'
          CidrIp: 172.16.X.X/32

Outputs:
  InstanceId:
    Description: The Instance ID
    Value: !Ref MyEC2Instance

＜例＞Amazon EC2の作成（AWS CDK/TypeScript）

import { Stack, StackProps } from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';

export class Ec2Stack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const vpc = new ec2.Vpc(this, 'MyVpc', { maxAzs: 1 });

    const securityGroup = new ec2.SecurityGroup(this, 'MySecurityGroup', {
      vpc,
      allowAllOutbound: true
    });
    securityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(22));

    new ec2.Instance(this, 'MyEC2Instance', {
      vpc,
      instanceType: new ec2.InstanceType('t2.micro'),
      machineImage: ec2.MachineImage.latestAmazonLinux(),
      securityGroup,
      keyName: 'my-key-pair'
    });
  }
}

const app = new cdk.App();
new Ec2Stack(app, 'Ec2Stack');

5．今後の社内AWS CCoE活動を通して

弊社の大瀧を筆頭に2024年に社内AWS CCoEが発足し、All Certで終わったらもったいないと大瀧リーダーに声をかけられて私も社内CCoEに参画することにしました。

過去の経験と今の職務上、自分で何ができるかを考えて過去に基盤構築とアプリケーション開発を少々、今はガバメントクラウドの加入支援でシステムモダン化方式等の提案をしていることから、これらを組み合わせてInfrastructure As Code（IaC）を中心とした活動ができればなぁと思っています。

私が考えた社内CCoE活動のロードマップとしては以下のとおりです。CCoE活動を始めたばかりではありますが、AWS関係者の方々と交流を深めつつ、2までは着実に進めていきたいですね。

お問合せはお気軽に

SHIFTについて（コーポレートサイト）

SHIFTのサービスについて（サービスサイト）

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO：UnsplashのGrowtika