selmertsxの素振り日記

ひたすら日々の素振り内容を書き続けるだけの日記

技術書展4に参加しました

技術書展にて、本を出す側で参加させていただきました。

techbookfest.org

TypeScriptを使って、AWS Lambdaを書く際の注意点などを記載しています。 実は、個人的に作っていたAWS Lambda製のchatbotについて記載したかったのですが、プライベートの諸々の予定と完全に被ったため時間が無く....今回は断念しました。次回こそは!

普通のLinuxプログラミング勉強会 9章 Linuxのディレクトリ構造

9.1 基本的な構造

ディレクトリツリーの標準規格であるFHS(The Filesystem Hierarchy Standard)に基づいて説明する

  • /: ルートディレクト
  • /bin: ブートするときに必要なコマンド (bash, ps, cp)
  • /sbin: ブート時に必要な管理者用コマンド (mount, reboot, ifconfig)
  • /lib, /lib64: ブート時に必要なライブラリ (libc.so.6とか)

9.2 /usrディレクト

基本的に複数のマシンで同じ環境を利用したケースがある。 そのときはNFSを使って、環境がインストールされているディレクトリをマウントする。

/usr/local/${package_name} にすると、管理には楽だがPATHを通すのが手間になる。

9.3 /varディレクト

/varは頻繁に書き換えられるファイルを置く。 /var/logとかがそれにあたる。

9.4 ルート直下の重要なディレクト

  • /etc: passwdやらmy.cnfやら、各マシン毎に必要な設定ファイルが置かれている
  • /dev: デバイスファイルが置かれている。
  • /proc: プロセスファイルシステム(プロセスをファイルシステム上に表現する仕掛け)がマウントされる。
  • /boot: Linuxカーネルのプログラム置き場
  • /tmp: 一時ファイル置き場。リブートしたら消える
$ sudo cat /proc/1/status
Name:   init
Umask:  0022
State:  S (sleeping)
Tgid:   1
Ngid:   0
Pid:    1
PPid:   0
$ file /boot/vmlinuz-4.9.77-31.58.amzn1.x86_64
/boot/vmlinuz-4.9.77-31.58.amzn1.x86_64: Linux kernel x86 boot executable bzImage, version 4.9.77-31.58.amzn1.x86_64 (mockbuild@gobi-build-64011) #1 SMP T, RO-rootFS, swap_dev 0x4, Normal VGA

「クラウドセキュリティ & プライバシー」読書メモ

目的

クラウド時代におけるIAMについて考える。

1章 クラウドコンピューティングの進化

産業時代、組織は電力を自給する必要があった。 電化によって、組織は電力を自給する必要がなくなり、 必要なエネルギーを必要なときに、必要な分だけ調達することが可能となった。 クラウドコンピューティングはまさしくこれと同じである。

2章 クラウドコンピュテーィングとは何か?

クラウドコンピューティングのためのSPIモデル

  • Software as a Service
  • Platform as a Service
  • Infrastructure as a Service

Software as a Service

これまでは、あるサービスを利用したい場合、Softwareを購入して自身のアプリケーション上で実行して、その結果を得ていた。 SaaSを活用すると、アプリケーションの管理やホスティングを自身で管理しなくても、そのサービスの恩恵を受けることが可能となる。 SaaSベンダーは、ソフトウェアのコピーなどを防ぐことができるというメリットもある。

Platform as a Service

ベンダーが開発環境自体をアプリケーション開発者に提供し、プロバイダのプラットフォーム経由でサービスを提供するもの。 細かいこと設定できない代わりに、アプリケーションの開発に集中させてあげるよ!って環境。 Herokuなどのサービスがこれにあたる。

Infrastructure as a Service

クラウドの基本要素から成るもので、ネットワーキング機能、コンピュータ、データストレージ領域へのアクセスを提供する。 リソースは渡すから自分でサービスを組み立ててねって印象。Amazon EC2やGCEなどがこれにあたる。

5章 Identity Access Management (IAM)

クラウドサービスを使うと、アンコントローラブルな領域がどうしても生まれてしまう。 その場合、セキュリティの強度を上げようと思ったら、アプリケーションセキュリティやユーザーアクセスコントロールなどを強くしなければならない。 その結果、二要素認証、アイデンティティ連携、SSO、ユーザ行動の監視・監査が重要になってきた。

IAMで重要なのは、集中的で自動化されたアクセスコントロールできるようにすること。 それによって、安全で効率化されたシステムを実現する。

IAMの定義

IAMではAAA(Authentication, Authorization, Auditing)の3つの要素が重要になってくる。

  • Authentication
    • ユーザーのシステムのアイデンティティを検証するプロセス
    • もっと簡単な言葉で言うと、通信の相手が誰か確認すること
    • 指紋などその人固有の情報や、パスポートなどの所有物、パスワードなどの知識を使って行う
  • Authorization
    • アイデンティティが確立されたときに、ユーザやシステムに与えられている特権を決定するプロセスのこと
    • とある条件に対して、リソースアクセスの権限を与えること
    • 駅で切符を買ったから電車に乗れるとかそういうの
    • 誰かに貰った切符で電車に乗るなど、移譲された権限を行使することもできる
  • Auditing
    • 認証のレビューおよび検査プロセス、認可記録、IAMシステムコントロールの妥当性を判断する
    • セキュリティサービスへの侵害を検知して、その対策を勧告する

この資料がよりわかりやすかった

https://dev.classmethod.jp/security/authentication-and-authorization/

IAMアーキテクチャ

IAMでは下記の運用アクティビティが存在する

プロビジョニング

ユーザーをシステムやアプリケーションにオンボーディングするプロセス。 ここでユーザーのロールや、アクセス可能なリソースの設定などの権限管理を行う。 これに対して、ユーザーに割り当てられた権限を剥奪することをデプロビジョニングと呼ぶ。

クレデンシャルと属性の管理

クレデンシャルとは、リソースにアクセスするために必要なものを指す。 例えばパスワードや、APIキーなどがこれにあたる。 クレデンシャルは、特定のユーザーにのみ結び付けられている。 属性とは、氏名、メールアドレスなど、ユーザーを一意に定めるために必要な情報を指す。

この資料を読みながら補足した。

https://dev.classmethod.jp/cloud/aws/iam-bestpractice-1/#toc-aws

エンタイトルメント管理

エンタイトルメントとは認可ポリシーとも呼ばれるもの。 リソースにたいしてユーザーがアクセスするために必要な権限のプロビジョニングとデプロビジョニングを担うプロセス。

コンプライアンス管理

アクセス権や権限は企業のリソースのセキュリティを確保するために、監視、記録がされている必要がある。 これにより、監査人が適切なアクセスコントロールポリシーを遵守しているか検証することもできる。

アイデンティティ連携(Federation)管理

Federationとは、ネットワークドメインを超えて確立された信頼関係を管理するプロセスのこと。 SSOを実現する際に役に立つ。 この機能を使うと、ユーザー情報を共有することなく、アイデンティティを連携することが可能となる。

認可と認証の集中化

認証・認可のためのインフラストラクチャを用意することで、開発者がアプリケーションに認証・認可機能を構築しなくて良くなる。 認証と認可の外部化とも呼ばれる。

学びまとめ

クラウドを活用する時代になって、IAMも変わってきた。

  • 安全・効率的にアイデンティティを連携したい
    • 認可・認証の機能を共通化させる
    • それによって、アプリケーション開発者は、認可・認証を気にせずにアプリケーション開発に集中できる
  • IAMでは認証・認可の他に Auditing という要素も重要になる
    • 認証・認可のログを取り、おかしなアクセスがあったら検知できるようにすること

JSとかRailsのログをWebPに変換してみた

概要

第4回SpeeeKaigiで、発表した資料です。 JSコードをWebPに変換してみました。

発表資料

speakerdeck.com

コード

github.com

参考資料

WebPの圧縮アルゴリズム

Compression Techniques  |  WebP  |  Google Developers

「成長する企業はなぜSSOを導入するのか」を読んだ

所感

SSOについて、必要性と実現方法の概要を説明している本です。SSOって何?って人がいたら、エンジニア・ディレクター問わず読んでおくと良さそうです。

Single Sign-Onとは

各種サービスへのアクセスを一つにとりまとめるもの。

before 社内で利用される各種サービスへのID/Passを覚えて無ければならなかった

after 全てのサービスへのアクセスは、SSOツールへのアクセスで一元化される。

SSOの実現方法

  • リバースプロキシ方式
  • エージェント方式
  • フェデレーション
  • クライアントエージェント方式

リバースプロキシ方式

ユーザーと業務システムの間に、リバースプロキシサーバーと呼ばれるサーバーを配置するもの。ユーザーからの認証リクエストを、認証サーバーに問い合わせる。ユーザーを代行して業務システムにログインする機能を持つSSOを使えば、業務システム側の認証機能を改修する必要もない。リバースプロキシサーバーを建てる際は、リクエスト数が増大するとそれがボトルネックになりやすい。

エージェント方式

業務システムにエージェントモジュールを組み込む。認証する際には、業務システムから認証サーバーに問い合わせをする。導入する場合、業務システムのプログラムを改修する必要がある。リバースプロキシが使えない場合に採用される。

クライアントエージェント方式

各ユーザーの端末にエージェントモジュールをインストールする方式。各業務システムをエージェントが認識し、ユーザーIDやパスワードをエージェントが入力する。

メリット: 業務システムへの改修が不要 デメリット: ユーザーのOS/利用ブラウザによっては適切に認証できないことがある

フェデレーション

認証基盤がクラウドだったり、オンプレミスだったりしても、それらを連携させてSSOを実現する方法。詳細は後程。

SSOシステムの機能

  • 代行ログイン機能
    • SSOシステムがユーザーに変わって業務システムにログインする
  • セッション管理機能
    • 業務システムへのログインセッションをSSOシステムが一括管理する
    • タイムアウト時間の設定等もSSOシステムが管理する
  • 情報継承機能
    • ユーザーの属性情報をSSOシステムが保存・管理し、業務システムへ渡す機能
    • 個々の業務システムでユーザー属性情報を保存・管理する必要がなくなる
  • アクセス制御機能
    • ユーザーから業務システムの各コンテンツへのアクセス可否を制御する
    • いわゆる認可機能
  • ダイナミックメニューポータル機能
    • SSOシステムへのログイン直後に業務システムへのリンクをメニューとしてポータル画面に表示する機能
    • あなたがアクセスできるツールはこれですよーみたいなもんか
    • ここにSentry、Datadog等々が乗れば良さそう
  • アクセス記録機能
    • 不正アクセスがあったときに、影響範囲をすぐに調査できる
    • 社内で利用されているサービスを可視化できる
  • windows認証との連携機能
    • windows PCにログインしたら、SSOシステムへのログインが不要になる機能

フェデレーション

それぞれ個別に認証機能を持つクラウドやサイト間でのシングルサインオンを実現する方法。この仕組みを使うことによって、パブリッククラウドサービスへの認証を一元管理することができるようになる。

SAML(Security Assertion Markup Language)

OASIS (Organization for the Advancement of Structured Information Standards)が定めた クラウドサービスと企業の間で認証の連携を行うための標準規格。

フェデレーションはパスポートの仕組みに似ている。自社でパスポートを発行し、クラウドサービス側ではパスポートが適切であればサービスへのアクセスを許可する。パスポートを発行する側を Identity Provider(IdP)。 クラウドサービス側を Service Provider(SP). このパスポート自体はSSOの世界では アサーション と呼ぶ。

SPがIdPを信頼できれば、そのIdPから生成されるアサーションの確認を、ユーザーの本人確認とみなす。一度発行されたアサーションは特定のSPへのログインにしか使えない。

SAMLによる実際の処理の流れ

  • ユーザーがIdPにアクセスしてパスワード等でユーザーへの認証を行う
  • IdPがアサーションを発行する
  • アサーションがWebブラザを介してSPに提示される
  • アサーションの正当性と信頼したIdPによる発行かどうかをSPが確認する
  • SPがユーザーに利用を許可する

参考資料

AWS Startup Daysでちょっとお話ししてきました

3/12 日のAWS Startup Daysというイベントでちょっとお話しさせていただきました。

aws.amazon.com

お話しさせて頂いた内容は Serverlessで作るchatbot。 弊社SpeeeにおけるServerlessの事例と一緒にお話しさせていただきました。

github.com

発表資料はこちらになります。ここ細かく知りたいっ!!!とかあれば、ブログで色々書いてくので、コメント頂ければ幸いです。

speakerdeck.com

LocalでDynamoDBを起動する

モチベーション

aws lambdaの開発において、開発効率の向上のためにlocalで動作が確認できるようにしたい。 そのためには、localでDynamoDBが動くようにしたい。ここでは、そのために必要な方法について記述する。

DynamoDBの起動

DynamoDB ローカル (ダウンロード可能バージョン) のセットアップ - Amazon DynamoDB

このページから、DynamoDBデータベースをDLします。 そして、下記のコマンドでDynamoDBデータベースを起動します。

# dynamoDB起動コマンド
java -Djava.library.path=./db/DynamoDBLocal_lib -jar ./db/DynamoDBLocal.jar -sharedDb

僕は、下記のようなコードを用意してコマンドで実行できるようにしました。

#!/bin/sh

CMDDIR="$(dirname "$(perl -e 'use Cwd "abs_path";print abs_path(shift)' "$0")")"

case "${1:-}" in
  deploy) shift 1; exec "$CMDDIR/prpolice-deploy" "$@";;
  dynamo) shift 1; exec "$CMDDIR/prpolice-dynamo" "$@";;
  local) shift 1; exec "$CMDDIR/prpolice-local" "$@";;
  setup) shift 1; exec "$CMDDIR/prpolice-db-setup" "$@";; # 今回追加したやつ
  *)
    echo 'Usage: prpolice <subcommand> [<args>]'
    echo
    echo 'Subcommands of pfchecker are:'
    echo '  deploy: deploy lambda function'
    echo '  dynamo: run local dynamo db'
    echo '  local: call lambda in local condition'
    echo '  setup: create local dynamodb table'
    echo
    ;;
esac
#!/bin/sh
cd "$(dirname "$(perl -e 'use Cwd "abs_path";print abs_path(shift)' $0)")"
cd ../
java -Djava.library.path=./db/DynamoDBLocal_lib -jar ./db/DynamoDBLocal.jar -sharedDb

Local DynamoDBにAWS CLIからアクセス

aws-cliを利用する場合は簡単です。 下記のoptionを設定すれば、
大抵のコマンドは動きます。 --endpoint-url http://localhost:8000

aws dynamodb create-table \
  --table-name User \
  --attribute-definitions \
    AttributeName=id,AttributeType=S \
  --key-schema AttributeName=id,KeyType=HASH \
  --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1 \
  --endpoint-url http://localhost:8000

ちなみに、aws cliのhelpを読んでも書いてありませんでした。

ローカルエンドポイントの設定 - Amazon DynamoDB

Local DynamoDBにaws-sdkからアクセス

import AWS from "aws-sdk";

const dynamo = new AWS.DynamoDB({
  endpoint: "http://localhost:8000",
  region: "ap-north-east1"
});

設定としてはこれだけです。下記のscriptを実行すると、LocalのDynamoDBにアクセスすることができるようになります。

# sample.ts
import AWS from "aws-sdk";

const dynamo = new AWS.DynamoDB({
  endpoint: "http://localhost:8000",
  region: "ap-north-east1"
});

const params = {
  TableName: "User",
  Item: { Id: { S: "SlackID" }, github: { S: "GitHubID" } }
};

const getParams = {
  Key: {
    Id: {
      S: "SlackID"
    }
  },
  TableName: "User"
};

// put Item
dynamo.putItem(params, (err, data) => {
  console.log(err);
  console.log(data);
});


// get Item
dynamo.getItem(getParams, (err, data) => {
  console.log(err);
  console.log(data);
});

まとめ

Local DynamoDBの実行に関して、ソフトウェアのダウンロードから、AWS CLI / aws-sdk でのアクセス方法について記載しました。案外簡単にできました。

その他

今考えたら Homebrewを使ってDLすればよかったですね。

brewformulas.org