会社の研修で…

今更だけど『AWS Dev Day Tokyo 2018』にちょっと行かせてもらったので報告。
『AWS Dev Day Tokyo 2018』とは何ぞや、というTipsは以下。

ただ正直これは失敗だった。理由はインフラエンジニアの自分が、アプリ開発の祭典行っても楽しめるわけがなかった（当たり前）。

アマゾン日本法人本社

立地はよくてアクセスも容易だった。建物内もオシャレでよかった。

Dev AWSome Day

じつはちゃんと参加したのはこのセッションだけだったりする。これも17時前には抜けたけど。

内容はAWSを使ったサーバーレスなアプリケーションを作ってみましょうというもの。教えてもらった通りにつくれば誰でもアプリが作れるセッションだった。今回は画像認識アプリみたいなものを作った。

システム図

学んだこと

一応いまセキュリティエンジニアなのでその視点で。

世界最大のECサイト“Amazon”を支える基盤技術を、クラウドサービスとして商品化したのがAWSである。いまやパブリッククラウド分野におけるAWSのシェアは34%（2017年時点）であり、事実上のデファクト・スタンダードと言える。

AWSの最大の特徴はその構造にある。シンプルで小さなサービスが機能ごとに100個以上提供されている。じつはAWSが最も効果を発揮するのは、そうした小さなサービス郡を連結させて巨大サービスを形作る場合だ。この小さなサービスはマイクロサービスアーキテクチャと呼ばれ、AWSの根幹を成している。言うなれば、AWSとはマイクロサービスアーキテクチャの集合体であって、その他の、単にサーバリソースを提供するだけのクラウドサービスとは明確に差別化されている。

AWSがこのような構造を持つに至った理由は、Amazonの開発経緯にある。当初Amazonもモノリシックな単一システムが採用されていたが、改修のたびにシステムを横断する影響範囲すべてをメンテナンスしなければならず、そのコストは膨大だった。そこで単一の巨大システムを小さく分解し・分散したまま連結稼働させる方針が採られた。システムを最小のサービス単位にまで分解・分散すれば、改修の際は、対象の小さなサービスのみアップデートすれば事足りる。改修による全体影響を斟酌せずともよくなれば、重い枷を外されたエンジニア達は、開発を加速度的に進めていく。

さらに言うと、モノリシックからマイクロサービスアーキテクチャへの基盤転換は、スケールしやすいクラウドサービスと抜群に相性が良かった。AWSのクラウド利用者は、必要なときに必要なぶんだけ、リソース・サービスの両方を利用できるようになったからだ。

もっとも、マイクロサービスアーキテクチャ化による利便性向上が良い結果だけをもたらすとは限らない。増えるに増えたサービスすべてを把握することは非常に困難だし、技術的にやや進みすぎているきらいがある。高度に発展したAWSは、きちんと勉強していない人間が扱えば、セキュリティ的に危険な状態を作り出してしまう。

AWSセキュリティの手習いとして、アクセスキー・IAMロール・署名の習熟は必須である。それぞれの説明は今回省くが、昨今ではそういった基本的な概念すら理解せずにAWSを使う人々も多く、セキュリティ事故が多発している。また、仮に理解していても事故が起こることもある。たとえば以前の私の職場では、Github上にソースコードをUPした際、うっかりアクセスキーまで載せてしまったエンジニアがいた。当然、不正利用され、翌月には100万円単位の請求書が来た。

上記はあくまでエンジニアの意識レベルの問題だが、最も深刻なのはAWSが最低限求める技術的水準に、ユーザー側が対応できない場合だ。各マイクロサービスアーキテクチャは攻撃側につけこまれやすいポイントも存在する。たとえばマイクロサービスアーキテクチャ間の連携をAPIで行った場合、そのAPIの接続制限は完璧にしておく必要がある。そうでない場合、攻撃者に悪用され、APIは秘匿しているはずの情報を吐き出し続けることになる。

今回はそれらマイクロサービスアーキテクチャのセキュリティ上の弱点を踏まえ、実際にアプリを作成した。使用したサービスはEC2、Cognito、S3、Lambda、DynamoDB、APIGateway、Rekognitionの7つである。 それぞれに良いところと注意すべき点があった。総括としては『包丁やライターだって無知な小学生が使えば危険なもの。しっかり勉強しなければ、AWSを使うのは難しい』と締めたい。