認証と認可について
はじめに
ネットワークスペシャリストの勉強をしていると、認証と認可がごちゃごちゃしてくるので改めて調査。 内容薄いが、アウトプット練習として投稿。
認証とは
認証(Authentication)
一言で言えば、
「通信の相手が誰か確認すること」
例えば、
ID、パスワードを入力することで、システムがユーザ本人であることを認識、識別することができる。
認証を正常に行うことで、ユーザに応じたサービスを提供することが可能となる。
認可とは
認可(Authorization)
一言で言えば、
「権限を許可すること」
例えば、
ID、パスワードを入力し正常だった場合、”ログイン処理を行う（ログインする権限を許可）”こと。
認可が正常に行われることで、ユーザはサービスを利用することが可能となる。
終わりに
認証と認可は、ログイン処理のように１つの流れに組み込まれているものが多く、字面も似ているので混乱しやすい。なのでログイン処理であれば 1. ID・パスワードの入力 2. システム側でユーザの特定 3. 正常であればログイン処理 のように流れを分解して、正確に例えと意味を紐付け理解できるようにしていきたい。
【読書メモ】『「自分の意見」ってどうつくるの？』
今回は『「自分の意見」ってどうつくるの？』という本を読んでみました。
読書メモとして残しておこうと思います。
概要
会議や話し合い、グループディスカッションなどで、
- 何を言えばいいのかわからない
- 当たり前のことしか浮かばない
- 他の人のコメントと同じだなんて言いづらい
のようなことで悩んでいる人たちに対して、フランス在住の哲学講師である著者が「フランス式思考法」を紹介する本。
印象に残ったこと
本書では、日本人とフランス人の考え方を比較しながら「フランス式思考法」が紹介されている。 その中で、フランス人とのエピソードを読んで印象に残った点をいくつか抜粋する。
一つは、フランス人の食事に関するエピソードについて。 フランス人は、ディナーは５時間かけることも珍しくなく、ディナーは「食事の時間」ではなく、「議論の時間」であるという。 日本での食事の時間は、仕事の会食でもない限りは、団欒の場だと私は思ってるので、文化が全然違うことに驚いた。
次に、著者がフランス留学して間もない頃のエピソード。 著者は、フランス人から以下のようなことを質問されることが多かったという。
- 日本人はどうして原発に反対しないの？
- 日本の領土問題について日本人はどう思っている？
- 日本の会社員はどうして休みが少ないの？
日本だと、原発や領土問題といった政治的要素が強いジャンルや、休みが少ないなどの日本人会社員の常識となっているようなことは、あまり話をしないので、自分の考えをパッと言える人は少ないと思われる。 著者も自分の考えというより、メディアで見聞きした内容を答えたそうだが、回答を聞いたフランス人からは不満気だったという。
これらのエピソードでもあるように、フランスでは、テーマにタブーなどもなく、さまざまな人の意見を聞き、受け入れ、考えの違いを楽しむ傾向が強いとのこと。 空気を読み、正しく的確な考えが求められる日本の文化ではこうはならないと思い、改めて文化の違いの面白さを感じた。
コメント
本書では、フランスでのエピソードを踏まえて、タイトル通り「自分の意見」の作り方を紹介している。 しかし、個人的にはフランス人エピソードから読み取れる「考えること」に対する考え方が最も大事なことに感じた。 「偉い人が考えてるから、そうに違いない」と自分で考えることをしない、違う考えを持つことを怖がるようなことをせず、「一人一人考えることが違って当然」ということを基本スタンスにできれば、楽しく成長できると思った。 また、これまで日本人以外の考え方を能動的に学びに行ったことがないので、ここも興味の範囲に入れると面白いかもしれない。
【読書メモ】『瞬時に「言語化できる人」が、うまくいく。』
今回は『瞬時に「言語化できる人」が、うまくいく。』という本を読んでみました。
本の要約練習、自分向けのメモも含めてまとめてみたいと思います。
概要
- 「言いたいことが、うまく言葉にできない・・・」
- 会議の時、上司や同僚から「どう思う？」と聞かれても、うまく答えられない
- 答えを求められると頭が真っ白になってしまうことも多い
このような経験で悩んでいるビジネスパーソン向けに「言語化力」を磨くメソッドが本書で紹介されている。
「思いをうまく言葉にできない・・・」がなくすために、本書は以下の目次で構成されている。
第1章 人は「伝え方」より「言語化力」で評価される
第2章 どうしたら「言語化」できるようになるのか？
第3章 瞬時に「言語化」できるようになるシンプルなトレーニング
第4章 瞬時に「言語化」できるようになるシンプルなトレーニング【実践編】
第5章 もっと「言語化」できるようになる方法【発展編】
印象に残ったこと
第1章〜第2章にかけて、コミュニケーション力（＝伝え方）と言語化力は別であることを著者は強調している。言われてみれば確かにその通り。私も含め、無意識に一緒にしてしまっている人は多いのでないかと思う。これまでも仕事でメールを書くを早くしたい、会議で発言できるようになりたいと、いくつか本を読んできたが言語化というワードは見てこなかったため、とても印象に残っている。
また、実際のトレーニング方法が以下のようにシンプルであることも良かった。
- A4縦書きの紙を使用する
- 問いを１つ決める
- 問いに対する「思考（どう思う？）」「理由（なぜそう思う？）」を芋づる式に書き出す
これを1枚2分1日3枚といった1日6分程度のシンプルなものであり、実践しやすい内容となっている点も良かった。
コメント
著者曰く、この言語化力トレーニングは、２週間もあれば効果を感じられるようになると言っているため、継続していきたい。
また、本書の趣旨とは少し外れるが、コミュニケーション力と言語化力の例のように、無意識に一括りにしてしまっていることが他にもあるように思う。もっと普段から物事を分解して考えることができれば、最も重要な部分に注力して取り組めるようになるのではと思った。
【読書メモ】「文章力が、最強の武器である」
前回投稿から1年近くが経ってしまいましたが、再び始めていこうと思います。
今度こそ継続していきたい・・・！
文章力を上げていきたいと思い、「文章力が、最強の武器である」という本を読んでみました。
本の要約練習、自分向けのメモも含めてまとめてみたいと思います。
概要
どんな文章（＝言葉）にも、人の心と、人の行動を動かす力がある。この力（武器）を正しく使うことで、「伝えたいことを正しく、自分らしく表現するため」「誰かの役に立つため」に使えるようにしなければならないと著者は主張している。 本書は、約30年書くことを仕事にしてきた著者が、正しく文章を書くための考え方、ノウハウが以下目次の構成でまとめられている。
目次 : 序章 文章力を磨くことで身につく「５つの力」/ 第１章 文章力が劇的に上がる「３つの視点」/ 第２章 文章の内容をおもしろくする「８つの考え方」/ 第３章 文章をわかりやすくする「５つの型」/ 第４章 文章を読みやすくする「８つのコツ」/ 第５章 文章力が身につくと、人生が変わりはじめる
印象に残ったこと
第３章で説明されている文章の"型"に関する記述が印象的だった。 本書では、
・文章を書き慣れていない人は、文章の論理展開が甘くなりやすい
・文章の論理展開が甘くなる理由として、"構成要素"と"書く順番"が決まっていないことにある
と述べており、"構成要素"と"書く順番"を意識するための文章の"型"が紹介されていた。
この文章の型については、私のような文章力に自信のない人でも入門編として意識しやすい点ではないかと思う。
コメント
文章の型について、後からでも見返せるように図式化してみた。
（初めての試みのため、程度の低い図であることはご了承ください）
本ブログ記事も、紹介されている型の中にある「自分の評価、感想を述べるときの型」である【概要説明⇨印象に残ったこと⇨コメント】に習って書いている。
実際に書いてみて分かったこととして、いつもある「どう書き進めていいか分からない・・・」が型に習って進めることでとても書きやすくなった。
最後に
今回初めて読書メモ、感想を書いてみましたが、時間のかかる分、記憶に定着しやすいと感じました。 練習も兼ねて継続していきたいと思ってます。
AWS DVA AWS開発 参考書読み７日目
今日やったこと
DynamoDBについてを読んだ
Amazon DynamoDB
優れたスケーラビリティ・拡張性を持つNoSQLデータベースを提供するサービス
エンドポイントを通じて、いずれかのアベイラビリティゾーンにあるノードにアクセスする
単一障害点がないことが特徴で、どこのノードからもアクセス可能
複数ノード間で整合性と取るために以下オプションを指定可能
DynamoDBの結果整合性のオプション
- 読み込み
- 結果生合成のある読み込み
- 2/3の読み込みで結果が一致した場合正常応答
- 強い読み込み整合性
- 全てのReadRepairが完了している状態で結果を応答
- トランザクション読み込み
- 直列化可能分離レベルでデータを読み取るオプション
- 結果生合成のある読み込み
- 書き込み
- 結果整合性のある書き込み
- 2/3以上の書き込みが成功した場合正常応答
- トランザクション書き込み
- 全ての書き込みが成功した場合正常応答
- 結果整合性のある書き込み
キャパシティユニット
DynamoDBの課金体系に２つのオプションがある
- オンデマンドキャパシティモード
- リクエストに応じて請求が発生する
- プロビジョンドモード
- 事前に必要と予想される読み込み・書き込みできるキャパシティユニットを指定する
キャパシティユニットの定義
読み込みキャパシティユニット
Read Capacity Unit: RCUs
- １秒あたりの読み込み項目数×項目のサイズ
- ４KBまでを１ブロックとして計算
- 例）３KBを読み込むリクエストが毎秒１０００回→１０００RCUs
- 結果整合性がある読み込みの場合はスループットが２倍
- トランザクション読み込みの場合はスループットが半分
書き込みキャパシティユニット
Write Capacity Unit: WCUs
TimeToLive(TTL)
項目に対して、有効期限（TTL）を設定可能
使用すると、指定された日時に、スループットを消費することなく、削除できる
DAX(DynamoDB Accelarator)
VPC内でキャッシュクラスタを構築し、DynamoDBのデータへ高速にアクセスできるキャッシュサービス
グローバルテーブル
複数のリージョンにまたがる共通のデータベース
通常は、リージョンごとにDBが分かれている
終わりに
結果整合性については、覚えるのもごちゃごちゃしそう
ユースケースと一緒にどういう使い方をするのが理想かと一緒に覚えていきたい。
AWS DVA AWS開発 参考書読み６日目
今日やったこと
API Gatewayの機能
認証・認可
IAMアクセス権限
AWS署名バージョン４を利用した認証と認可を行う
クライアントはAWS署名バージョン４をHTTPリクエストヘッダに設定して、API Gatewayにリクエストを送信する
AWS署名バージョン４
IAMユーザのアクセスキー（アクセスキーIDとシークレットアクセスキー）を元に作成したハッシュ値
Lambdaオーソライザ
名前の通り、Lambda関数を利用した認証と認可を行う
クライアントは、Bearerトークンもしくは、HTTPリクエストヘッダのパラメータに認証情報を付与したリクエストを送信する
Bearerトークン
読み方：ベアラートークン
トークンを所有していることで、認証と認可がされる仕組み
Bearerトークンは、リクエストの送信元を確認しないため、第三者にトークンが漏れたら第三者の認証と認可ができてしまうため、注意が必要
Cognitoオーソライザ
名前の通り、Amazon Cognitoを利用した認証と認可を行う
クライアントは、Cognitoのユーザープールで認証を行ってトークン（Json Web Token）を取得し、HTTPリクエストヘッダにセットしてリクエストを送信する
JWTオーソライザ
OpenID ConnectまたはOAuth2.0の一部として、JWTを利用した認証を行う
クライアントは、OpenID ConnectまたはOAuth2.0で認証を行なってトークン（JWT）を取得し、HTTPリクエストヘッダにセットしてリクエストを送信する
相互TLS認証
サーバがクライアントにクライアント証明書を要求して検証を行い、接続元クライアントの正しさを確認することにより、クライアントとサーバの双方向の認証をサポートする
スロットリング
トークンバケットアルゴリズムでは、１リクエスト処理する度にバケット内に保持していたトークンを１つ消費する
トークンの補充速度を「定常レート」、バケット内に格納するトークンの最大サイズを「バースト」と呼ぶ
APIのキャッシュ
API Gatewayではステージごとにキャッシュを定義し、バックエンドのトラフィックを削減することができる
カナリアリリース
任意のステージに対して、「Canary」という特別なステージを定義できる
API Gatewayへのリクエストを、指定した比率でCanaryステージへ分配することができる
WAF連携
WAFのACLを指定することで、SQLインジェクションやクロスサイトスクリプティングなどのセキュリティ攻撃を防ぐことができる
監視連携
CloudWatchやX-Rayとシームレスに連携でき、リクエストの処理パフォーマンス分析やデバッグが可能になる
終わりに
TLSって言葉が出て来るたびにググって「あ〜これだった」となるのでそろそろ覚えたい
AWS DVA AWS開発 参考書読み５日目
今日やったこと
今日は、AWS DVA（デベロッパーアソシエイト）の参考書で、API Gatewayについて途中まで読んだ。
Amazon API Gateway
オンラインサービスへのリクエストを受け付ける機能を提供するサービス
以下３種類のAPIを作成可能
REST API
RESTアーキテクチャスタイルに基づき、ステートレス通信を行うAPIを提供
クライアントからリクエストを受け付けるエンドポイントは３つ
エッジ最適化APIエンドポイント
Amazon CloudFrontのエッジロケーションを使用してクライアントの最寄りの接続ポイントにルーティング
リージョンAPIエンドポイント
指定したリージョンにAPIエンドポイントをデプロイし、同一リージョン内のクライアントにサービスを提供
プライベートAPIエンドポイント
パブリックなインターネットからは分離して、アクセス権限を持ったVPCエンドポイントからのアクセスに限定する
WebSocket API
WebSocketプロトコルを使用して双方向のステートフル通信を行うAPIを提供
WebSocket APIでは、リージョンAPIエンドポイントが利用可能
HTTP API
REST APIと同様に、HTTPリクエストの中継を行い、ステートレス通信を行うAPIを提供
エンドポイントタイプとして、リージョンAPIエンドポイントが利用可能
ステートレスとステートフル
ステートレス
入力の内容によってのみ出力が決定される方式
ステートフル
同じ入力に対する出力が常に同じとは限らない
内部で保持している状態次第で出力が変化する方式
終わりに
REST APIのRESTってそこまでよく分かっていない。
これも他サービスと同様に実際に構築とかしてみないと分からないのかも。
ひと通り読み終わったら、理解曖昧な箇所は料金と相談して実構築してみたい。
